[Feature] Support exclusion/inclusion of parameters based on values

[ebousse]

PICT provides a straightforward and clean way to define your combinatorial testing problem, through the definition of a set of parameters, a set of values, and a set of constraints. All problems can be treated with these simple three ingredients.

There is though a recurring case where the value of a given parameter may completely exclude the role of other parameters, or conversely where a parameter may require the presence of another value. For instance, consider a procedure that validates the content of a string. If a parameter value expresses that the string can be null, then when this value is used, all parameters that describe the content of the string become irrelevant and should be excluded.

One way to solve such case is to rely on what the PICT documentation call "dummy values", where each parameter that may be wholly "excluded" gets an additional dummy value corresponding to such excluded state (eg. "NA"). Then constraints are added to ensure these dummy values are present when specific values are picked.

However, as the documentation itself explains, using dummy values can quickly become quite cumbersome (eg. if a parameter A may exclude a parameter B, which in turn may exclude a parameter C, etc.). Indeed, not only must one add "dummy" values in each parameter that requires it, but one must write quite verbose and error-prone constraints each time.

---

Yet in the combinatorial testing literature, a widely used model is the classification tree, which adds the possibility to organize parameters in a tree structure, and thus to explicitly tie a given parameter P to a given value V. When such tie happens, P can only be given a value if the value V was picked. This solves exactly the same problem as the one state above, except that it only requires defining an explicit first-class "inclusion" relationship between a value and a parameter, instead of having to manually define "dummy values" and their corresponding constraints.

My proposal is therefore the following: could we imagine in the future supporting a similar first-class mechanism in PICT, where a parameter could be included/excluded by the selection a specific value, thereby giving the possibility (among other things) to define actual classification trees?

As a very simple example, consider a procedure that checks whether a list is empty. We know that the procedure should produce an exception if the list is null, and we know it should return a result (true or false) depending on the amount of elements in the list. We therefore choose to prepare the following test model:

List_is_null: false, true
Number_of_elements_in_list: zero, more_than_zero

If the list is null, then we would like Number_of_elements_in_list to be excluded. Hence with the "dummy value" technique we would write:

List_is_null: false, true
Number_of_elements_in_list: zero, more_than_zero, NA

IF [List_is_null] = true
  THEN [Number_of_elements_in_list] =  "NA"
  ELSE [Number_of_elements_in_list] <> "NA";

Instead, we could imagine writing something like this (with some imaginary EXCLUDES keyword):

List_is_null: false, true
Number_of_elements_in_list: zero, more_than_zero

[List_is_null] = true EXCLUDES Number_of_elements_in_list

Or conversely (with some imaginary REQUIRES keyword):

List_is_null: false, true
Number_of_elements_in_list: zero, more_than_zero

Number_of_elements_in_list REQUIRES [List_is_null] = false

And with either model, we would expect to have PICT generate us the following set of cases:

• true, −
• false, zero
• false, more_than_zero

where − is our (automatically generated by PICT) dummy value for the Number_of_elements_in_list parameter.

I believe this could be achieved mostly in the form of "syntactic sugar" that would, behind the scene, add all required dummy values and corresponding constraints in the model?

[eidermauricio]

@ebousse good ideas they will make the PICT file more readable, because the dummy value technique is cumbersome and adds more complexity to other constraint's predicates.