Allow configuring type of NA

[tkruse]

Hi, in 2.0.0 the new class VarNaDef has no type.
However, when writing tests, a given variable being not applicable might be an error case, a valid case, it might even have the ONCE hint. Meaning as a tester, I might want to generate e.g. pairwise combinations with a given variable being assigned NA, or maybe just a single one where it is a failure.

So I don't understand the restriction.

And because it has a private Constructor, I have a hard time patching this.

I use NA for null values e.g. when passing Strings to a function. Else I would have to encode "null" as a different String value than NA, but to me it seems that java null is pretty much the same as TCases NA.

[tkruse]

I think I can just create my own SubClass to VarValueDef that returns true for isNA() for now, since VarNaDef is has no other functional use than overriding that method.

[kerrykimbrough]

The concept of "not applicable" here represents the situation where a variable is irrelevant to the test case -- its value is meaningless or non-existent (or perhaps "any will do"). VarNaDef acts as a marker of this situation. It's not part of the actual input model. As a tester, you can't choose how to use it. It's assigned by the system based on the constraints. By definition, it is valid (can occur in either success or failure cases) and can have no input properties.

[kerrykimbrough]

I admit that the VarNaDef implementation is hacky. VarNaDef and VarValueDef really ought to be sibling subclasses of a more abstract base class. But I wasn't willing to make such a big and incompatible change to the class structure.

[kerrykimbrough]

No change planned to current "not applicable" concept.

[tkruse]

Putting it differently, say I want to test a function taking n String arguments. And I want to generate testcases where for each argument, the test values are: ["", "a", "ab", ..., null]. How do you suggest this intention (using a null value) should be represented in Tcases in the FunctionInputDef and the TestCaseDef?

As a tester I can choose a dummy String value like "<use_null>", and then when running the test do the transformation, but to me that looks dirty. TCases prevents me still from using a VarValueDef with variable value null in VarValueDef.setName(). But I can currently use a VarValueDef with a custom name hidden from the user and isNA() returning true, yielding an XML where no dummy String appears, and I can still add conditions and properties. Maybe that is an abuse of the NA concept, but currently to me it seems preferable to the alternative of using a fake string value.

[kerrykimbrough]

How do you suggest this intention (using a null value) should be represented?

I see now that this is the real issue. And, yes, this is totally different from NA.

I suppose the real question is if DefUtils.isVarValue should accept a null String. I can see why allowing null could make sense when operating only at the API level. But it's harder to represent in all the externalized forms of Tcases input and output.

For the moment, I would just use a name for this value, e.g. "null".

[tkruse]

I created #35 to track this. I am not sure what further representations could suffer. To me it still seems for input in XML, null should be easily representable, and for output null values would be no different (in terms of effort) from the current NA values in all externalized forms of output.

E.g. When an XSLT rule has to be able to cope with an NA value to create testing code, I think it would do the same as for a null value. That's why I think NA and null are very similar in SystemTestDefs.