Would there be a value property that could be carried to the output file, linked to the value, similarly to "failure="true" " ?

29 views
Skip to first unread message

Juglar

unread,
May 6, 2015, 7:29:41 AM5/6/15
to tca...@googlegroups.com
Hi,

I have seen that the tcases -test output file for a failure case includes the following line for the bad value:

 <Var name="var1" value="BadValue" failure="true"/>

where the failure="true" property is linked to the bad value in its appearance in the file.

To automate as possible the transportation of the tcases output (through the xslt translation and C macro preprocessor) , I would need another property (as, for example, secondValue="AlternateValue"), to be carried as well by tcases from the input definition file to the output file, linked to the value.

My problem is that the value name in the input definition file doesn't accept any separator (like ",") that the C preprocessor could use to separate two parts of just one value identifier.

Would there be such possibility now or in the near future?

Thanks,
Jose


Kerry Kimbrough

unread,
May 6, 2015, 9:15:03 PM5/6/15
to tca...@googlegroups.com
Jose, I'm glad you're experimenting with different output transformations. You're discovering some features that could make this easier. 

Tcases is choosing variable bindings and assembling them into test cases. There ought to be a way to propagate properties of these choices to the output for further transformation. For example, what if you could associate a list of key-value pairs with each <Value>? And what if each output <TestCase> included the full list of all key-value pairs for each <Value> included?

Juglar

unread,
May 7, 2015, 5:55:00 AM5/7/15
to tca...@googlegroups.com
Yes, Kerry. I think that propagation would have a great potential. And it would cetainly be very useful for my current needs.

It would leave the input designer full control over it.

I would (by default, unless prevented by an invocation option) exclude from the output the tcases "reserved" value key words (like property, when, whenNot, etc). 

Or, alternatively, tcases could by default work as it does now (warning about unexpected keys in the <value>), and, when an invocation option is present, propagating transparently all the included key-value pairs (even the "reserved" ones, that could also be processed by the xslt).

Thanks,
Jose

Kerry Kimbrough

unread,
May 7, 2015, 10:50:44 PM5/7/15
to tca...@googlegroups.com
Here's how I'm thinking it might work. Please tell me your thoughts.

It starts with the concept of an "annotation" for a <Value>. An annotation is a property that has the special form "Name=Value". An annotation is just like any other property. It can be added to a "property" attribute, and it can be referenced in a "when" or "whenNot" attribute, etc. For example:

<System name="Examples">
    <Function name="Properties">
        <Input>
            <Var name="Foo">
                <Value name="this" property="P1, N1=V1"/>
                <Value name="that" property="N1=V2"/>
            </Var>
            <Var name="Bar">
                <Value name="something" when="N1=V2"/>
                <Value name="else" when="P1"/>
            </Var>
        </Input>
    </Function>
</System>

The difference is that, unlike basic properties, annotations are propagated to the generated test case definitions. For example.

<TestCases system="Examples">
  <Function name="Properties">
    <TestCase id="0">
      <Input type="arg">
        <Var name="Foo" value="this"/>
        <Var name="Bar" value="else"/>
      </Input>
      <Properties>
          <Property name="N1" value="V1"/>
      </Properties>
    </TestCase>
    <TestCase id="1">
      <Input type="arg">
        <Var name="Foo" value="that"/>
        <Var name="Bar" value="something"/>
      </Input>
      <Properties>
          <Property name="N1" value="V2"/>
      </Properties>
    </TestCase>
  </Function>
</TestCases>

 

Kerry Kimbrough

unread,
May 8, 2015, 4:09:41 PM5/8/15
to tca...@googlegroups.com
On further reflection, it makes more sense to propagate all properties to the <TestCase>. A simple property value (say, "P") could be considered equivalent to "P=true". Rather than creating a new concept of "annotation", it's better to simply generalize the existing property concept.

For backward compatibility, there should also be an option to turn off property propagation.

The new general Name=Value form of a property introduces the possibility of a conflict. For example:

<Var name="A>
  <Value name="A1" property="P=X"/>
</Var>
<Var name="B">
  <Value name="B1" property="P=Y"/>
</Var>

For a <TestCase> that includes A.A1 and B.B1, what is the value of property P? I'd say this should be an infeasible combination. As if there is also a hidden condition whenNot="P=*".

Kerry Kimbrough

unread,
May 8, 2015, 7:30:37 PM5/8/15
to tca...@googlegroups.com
The XML encoding for each Tcases document should follow a well-defined schema that specifies the attributes allowed for each element, and the parser should report an error for any unknown attributes. For that reason, we want to avoid adding user defined attributes for any XML element. That's why I propose to continue listing all property values within the value of the "property" attribute.

Another issue is how the propagated properties should be shown in the test definition document. You've suggested that the properties for each <Value> should be shown in the corresponding output <Var> element. On further reflection, I think you're right. Otherwise, potentially useful information would be lost.

You also suggested that the output <Var> element should have a property attribute that is identical to the one in the corresponding input <Value> element. But that would force transforms to decode the Name=Value encoding of these bindings. Explicit <Property> elements for these will make life easier for transforms.

So here is what I'm proposing now. Given an input document like this (note the alternative use of a <Property> element ):

<System name="Examples">
    <Function name="Properties">
        <Input>
            <Var name="Foo">
                <Value name="this" property="P1, N1=V1"/>
                <Value name="that">
                  <Property name="N1" value="V2/>
                </Value>
            </Var>
            <Var name="Bar">
                <Value name="something" when="N1=V2"/>
                <Value name="else" when="P1"/>
            </Var>
        </Input>
    </Function>
</System>

The output document would look like this:

<TestCases system="Examples">
  <Function name="Properties">
    <TestCase id="0">
      <Input type="arg">
        <Var name="Foo" value="this">
          <Property name="P1" value="true"/>
          <Property name="N1" value="V1"/>
        </Var>
        <Var name="Bar" value="else"/>
      </Input>
    </TestCase>
    <TestCase id="1">
      <Input type="arg">
        <Var name="Foo" value="that">
          <Property name="N1" value="V2"/>
        </Var>
        <Var name="Bar" value="something"/>
      </Input>
    </TestCase>
  </Function>
</TestCases>

Kerry Kimbrough

unread,
Oct 19, 2015, 4:41:18 PM10/19/15
to Tcases Forum
The capability discussed here is now implemented in Tcases. See Using Output Annotations.
Reply all
Reply to author
Forward
0 new messages