Tutorial Testing with a collection of inputs - Gnorion/BizVR GitHub Wiki

Tutorial Testing with a collection of inputs

In the previous section we showed how to set up the decision for execution as a function with three input arguments (color, size and shape). Each time you want to determine a price you need to call the decision with those three arguments. Generally this is how most decisions are structured.

But suppose you want to invoke the decision ONCE and pass it a collection of MANY values of color, size and shape?

For example, maybe color, size and shape are characteristics of things called TOYS. In json we might represent this as:

{ "TOYS":[ {"color": "red","shape": "square","size": "small"}, {"color": "green","shape": "round","size": "large"} ]}

At this point I recommend you make a copy of the decision. To do this click the down arrow to export the json form of the decision model image

It will look like this. Just click the CANCEL button

image

And then exit to the project window: image

Now click on the up arrow to see this screen. Make sure to give the new project a distinct name and then click IMPORT:

image

You should then see a copy of your decision in the project window.

Click on the decision. It should look exactly like the original. image

To handle collections of toys we will need to make three changes:

  1. Inputs will need to refer to the collection TOYS rather than the individual fields color,size and shape.
  2. Outputs will also need to refer to the collection TOYS
  3. The decision table will need to be modified to handle the collection

Inputs and Output changes image

Here are the changes to make to the decision table (we'll go through what they mean a bit further down)

CAUTION - make sure you use curly braces { and }

image

After making these changes, the decision diagram will look like this

image

Some explanation: The expression {toy in TOYS} tells the decision table to apply the rules one toy at a time to every toy in the input collection. Each toy is processed independently of every other toy. For each toy the rules will determine the price. At the end the updated TOYS collection is returned.

Now you should be able to run a test with multiple toys:

image

What happens if you run a test for small green square?

image

You get no price. That's because there is no rule for that particular combination. Actually there are many other combinations for which price is undefined.

So how can we identify those cases?

Well, we could create a test case for every combination. Since there are two possibilities for color, size and shape there are 2x2x2=8 possible test cases. Not too hard to create those by hand. But what if there were seven colors (red, green, blue, white, yellow, purple, orange) and there were seven sizes (miniscule, tiny, small, medium, large, huge, gargantuan) and seven shapes (square, round, oval, cubic, oblate, tetrahedral, rhombicosidodecahedral)? Then we would have 7x7x7=343 different combinations. That would be time consuming to create by hand.

So is there a way we can automate this? Yes, of course. Tutorial Automating test data generation