Validation and Testing in Stages - Gnorion/BizVR GitHub Wiki

I think figuring out what inputs are needed for testing is simpler than we thought.

There are really just two cases:

  1. Any Single table or expression in the hierarchy

  2. Any subtree in the hierarchy

For case 1 the inputs must be all variables used as conditions in that table ( or expression) whether or not they have ovals.

For case 2 it’s all the ovals anywhere in that tree all the way down to the terminal nodes.

This should make it easy to figure out the variables that go in the inputs array

There’s really no need to pick out unconnected tables, or tables in the midst of the hierarchy.

You always want a complete branch down to the terminal nodes.

So the scope of the test is defined entirely by the table you choose as the root node of the tree. That’s how the EE works anyway.

The user has the option to “comment out” a branch of the tree that’s already been proved simply by removing a dependency arrow - but they will need to insert an expression or table to provide the values that branch would have provided. But now you only need to worry about the possible outputs from that branch, not all of the combinations of inputs.

This is a way to control the potential explosion in the number of test cases if you have all the rules in play.

In TLP there are 1728 test cases in total if you take every possible combination of every input variable.

But you can reduce this number considerably by partitioning the testing

So when the user is editing a single table, validation will check just that table (and generate test cases for just that table) When the user is viewing the DRD then we do need the user to tell us what part of the DRD to validate. The whole thing or a particular branch of it (the default right now is the entire DRD).

So in this model

image

we could validate the entire model with all five tables together and VV would detect any conflicts across the tables. This probably would be done after validating all the individual tables

Or we could separately validate (and test) each of the five individual tables (usually the first step done as we create each table)

Or we could work with the three branches (probably just during testing to generate subsets of test cases)

image image image

Picking arbitrary unconnected tables like this is meaningless and should not be possible

image