Feature request: grouping of properties in a new property generated from a logical expression of other properties

10 views
Skip to first unread message

Juglar

unread,
Jul 23, 2015, 6:12:57 AM7/23/15
to Tcases Forum
I think it could be quite interesting that Tcases offered the possibility of grouping of properties in a new property generated from a logical expression of other properties, and I wouldn't expect it to be very costly to implement. 

In cases with many variables, many of which may depend (or some of its values) on the same intermediate condition (which could be expressed as an intermediate property), It would allow a more concise modeling and, more important, it wouldn't require the user to repeat possible modifications of that intermediate condition expression to all the variables (or values ) depending on it.

Thanks,
Jose

Kerry Kimbrough

unread,
Jul 26, 2015, 5:17:56 PM7/26/15
to Tcases Forum, jgl...@gmail.com
Interesting idea!

Consider that a property is a simple thing that either exists or not. It's not meaningful to think of defining complex properties.

But you can also think of a property P as a boolean expression that means "test case has property P". That's the meaning of a property name when it is used as a condition, i.e. in when, whenNot, or <When>.  And it is certainly helpful to think of defining complex conditions.

Below is an example of how it might look. What do you think?

Named conditions can be defined inside a <Define> element. Conditions can be defined for a <System>, in which case they apply to all functions, or for a single <Function> only. A <Condition> definition can have either of the two usual forms.
  • either a combination of "when" and/or "whenNot" attributes (see line 4)
  • or the same kind of boolean expression elements used in a <When> element (see line 10)
Afterward, the name of a <Condition> can be used like a property name in any conditions, i.e. when, whenNot, or <When> (see line 20 and line 23). But it would be an error for a <Condition> name to appear in a property assertion (see line 28)  --  a property is a condition, but a condition is not a property!

    1  <System name="Examples">
    2      <Define>
    3          <!-- Conditions defined here are visible to all functions -->
    4          <Condition name="c1" when="p, q, r" whenNot="x, y, z"/>
    5      </Define>
    6  
    7      <Function name="WithDefines">
    8          <Define>
    9              <!-- Conditions defined here are visible only to this function -->
   10              <Condition name="c2">
   11                  <AllOf>
   12                      <Not property="p"/>
   13                      <AnyOf property="q, r"/>
   14                  </AllOf>
   15              </Condition>
   16          </Define>
   17  
   18          <Input>
   19              <Var name="V">
   20                  <Value name="A" when="c1" whenNot="c2"/>
   21                  <Value name="B">
   22                      <When>
   23                          <AnyOf property="c1, c2"/>
   24                      </When>
   25                  </Value>
   26  
   27                  <!-- No! Can't use a condition name here. A <Condition> is not a property. -->
   28                  <Value name="C" property="c1"/>
   29              </Var>
   30          </Input>
   31      </Function>
   32  </System>

Juglar

unread,
Jul 27, 2015, 9:14:44 AM7/27/15
to Tcases Forum, kerryki...@gmail.com
Yes, Kerry:

I think how you present it, it is perfectly useful and very similar to what I was thinking. My naming of "new property" or "derived property" for that "item" derived as a complex logical expression from other properties was in relation to its possibility of being included in a condition expression, the same as a elementary property. So, I agree with you in the distinction between properties and conditions. I would also allow the possibility of using conditions defined elsewhere as properties in the definion of new ones).

The separation between System and Function scope is an additional feature, that can also be useful.

Anyway, as these features are mainly for user convenience, I would not issue a new version just for them, but keep them ready to be grouped with other new features in any future version.

Thank you and regards,

Jose

Reply all
Reply to author
Forward
0 new messages