The Use Case

Suppose you have some rules that operate on a data payload that can have many possible combinations of data values. During testing how can you be sure that you have covered all the possibilities? Including all the possible ways the data can be bad? Running your test against production data probably won’t help. Even though you may have millions of records, chances are you won’t find every possible combination of the data.

So is there a way that Corticon could help to generate test data?

Yes, Of Course!

Let’s imagine we have some business rules that evaluate meals at a restaurant.

A meal consists of a starter, an entrée, two sides, dessert and coffee

For example here are some possible meals

Starter is Soup or Salad

Entrée is Chicken or Beef

Sides are Fries, Peas, Carrots, Broccoli

Dessert is Ice Cream or Soufflé

Coffee is Regular or Decaf

Here are a few possible meals

soup, chicken, broccoli, fries, ice cream, decaf

salad, chicken, broccoli, fries, ice cream, regular

soup, chicken, carrots, fries, no dessert, regular

soup, chicken, broccoli, fries, ice cream, regular

salad, beef, broccoli, fries, ice cream, decaf

soup, chicken, broccoli, carrots, soufflé, decaf


If we also know the price (or calories) of each of the meal components we can compute the total cost (calories) of each meal.

Perhaps we want to determine which meal is cheapest or has least calories

Vocabulary

Mark Dinner entity as persistent and specify the key(s)

Create DB schema from Vocab



Create the allowable values for the various attributes:

Simply by adding more entries we can allow different kinds of soups.

We could even make the generation of items the subject of conditions.

For example prime rib is only available on weekends; Soufflé requires a minimum of two people.

Generate all possible combinations

Notes:

  1. Just specifying the entities in the scope causes Corticon to consider all combinations
  2. Filter 1 ensures we pick two different sides
  3. Ensures we only get each pairing once regardless of the order
  4. Rule 1 is just there to generate the message AFTER all the dinners have been constructed
  5. Action A creates a new dinner for each combination of the components
  6. It also calculates the total price of the dinner

This rule sheet removes all but the least expensive dinner:

If there happen to be two or more least expensive options they will be left.

Rule Flow:

Test Case

If we also want to clean up the various component items we can use this rule sheet

Computing Statistics

Results

Updating a database using the tester

Just set the test sheet to update:

After execution the database contains:

 

Enhancements

If necessary we could impose constraints on the construction of meals.

Eg. Suppose we could choose any two starters providing one of them is not smoked salmon

Download

Download PDF version.