Defining Validator Behavior Using Decision Tables - Gnorion/BizVR GitHub Wiki

We can use our own decision tables to define the various behaviors and messages for the various ways in which objects may be absent from the model:

That means we can verify the logic expressed here

It also means we can generate the test case required e.g.

This does cover EVERY possible combination (32 possible combinations of which only 7 really make any sense).

However it also includes combinations which are not possible e.g.

You cannot have conditions and actions without a rule for them to belong to (knowledge we have from outside the system)

But of course there is no way for the test data generator to know that.(see note 1)

Unless we provide a way (in a bizVR decision table) for the user to define how they would like the test data generated - that would be cool.

Actually it can already be done with BizVR:

https://github.com/Gnorion/BizVR/wiki/Defining-Test-Data-Using-Decision-Tables

https://github.com/Gnorion/BizVR/wiki/Defining-Complex-Data-Using-Decision-Tables (this allow for the creation of test cases that have hierarchical structures)

(notes 1) Actually there is: If we assume that the rules as written correctly express the behaviors AND that valid associations between the objects then rule 7 is telling us something about what is possible and what is not:

If there are NO decisions then none of the other conditions make any sense - BizVR simply cannot create an export file with rules if there is no ruleset object to put them in. When the data elements are not part of a hierachy them any combination may be possible - so in general the VV exhaustive approach is the safest one to take.