Admit properties also in failure values

[juglar]

Removing the current prohibition (which, moreover, is not documented) to include properties in failure values would open more possibilities to the user.

For example, it would allow the model definition to specify which of the success values in other variables would be chosen in the fail test case for the failure value of a variable.

Also, if there is a Var1 variable which is conditioned (through a “when” condition) on a Var2 variable property, it would allow a value different from “NA” to be assigned to Var1.

[kerrykimbrough]

Sorry, I don't understand the last comment about "allow a value different from NA". Can you clarify?

[kerrykimbrough]

Actually, there is a fundamental reason why failure values can't have properties, so this restriction is necessary. But there are still ways to control the value of other variables in failures cases.

Suppose value=V defines property=P. But why? So that some other value=X can require combination with V (or any other value that defines P). But if V is failure=true, that doesn't make sense. If X is valid, it can't demand combination with a failure value. And if X is a failure value, it can't demand combination with a different failure value.

But a failure value can define conditions. In other words, it can demand combination with specific values from other variables. By working from this direction, you can control the other values used in a failure case.

At any rate, the existence and reason for this restriction ought to be explained in the Tcases Guide.

[juglar]

In my particular case, for several variables, I have from 1 to 3 value ranges (equivalence classes) and I include their extreme values as the variable values to test in the success cases. However, for failure test cases, I usually prefer that they use a more central value for each variable (usually, its default value), with which the SUT behavior is more normal and recognizable and, moreover, it provides more confidence that the checked failure is due to the failure value and not to a possible combination of several success extreme values which may not have been covered by the success cases. This is the reason why I want a special success value for each variable to be the one used in combination with the failure values of the other variables (in more complex situations, there could be more than one special success values for the same variable, depending on which failure values it would be combined with).

In your example, I think that it would make sense that failure value=V defined property=P, so that all other success values of other variable W, except for the central value C intended to be combined with V, could exclude their combination with the condition whenNot=“P” and, that way, force Tcases to choose C as the success value to be combined with V.

However, the solution that you propose (and that I didn’t think was possible) of specifying conditions, instead of properties, for the failure values is perfectly valid for same purpose, so I agree that it’s not necessary to allow properties in them.

Actually, the trick that I’m now using is transferring all the failure tests to a separate Tcases model file, with all the variables, each of them containing all its failure values plus just one success value (its central value). It is perfectly useful for me (though at the expense of dividing the tests for each variable at least into two test models, the success and the failure ones). If I needed to select between more than one success case depending on the failure values to combine with, I could use those failure value conditions.

Thanks.

[juglar]

But about the last case I commented, that I quote again:

"Also, if there is a Var1 variable which is conditioned (through a "when" condition) on a Var2 variable property, it would allow a value different from "NA" to be assigned to Var1."

I try to clarify it with the following example, written as if failure values did allow properties:

For failure value SupMax of Var2, Tcases would have to use the value Central for Var1 (as the other success value, Min, would be excluded by its whenNot condition).

However, if property Big is not allowed for that failure value SupMax of Var2, TCases will select "NA" for Var1 (as Big, required by the "when" condition of variable Var1, is not provided by any value), This behavior doesn't let me specify a central value to be combined with the failure value. I don't see how conditions in failure values could allow me to achieve the same objective.

Thanks

[juglar]

Sorry, the web eliminates my xml example code and doesn't even allow me to enclose it as a text file !
(I would welcome suggestions as to how to enclose here fragments of xml files). So, I enclose it as an image !

[kerrykimbrough]

Here's how you can get the same effect with failure conditions.

<Var name="Var2">
    <Value name="SupMax" failure="true" when="NormalVar1"/>
    <Value name="Max"/>
    <Value name="Min" property="NormalVar2"/>
</Var>
<Var name="Var1" whenNot="NormalVar2">
    <Value name="SupMax" failure="true"/>
    <Value name="Central" property="NormalVar1"/>
    <Value name="Min"/>
</Var>

[juglar]

That seems a good solution !

Thanks