Unit Tests Advanced

This document demonstrates advanced techniques of using Unit Test utility in Decisions Designer. To start with Unit Test utility please go through Unit Tests Overview (Simple Flow) document first. This document demonstrates the advantages of using Unit Tests on Complex Data Types, Step Simulation Options, and Running Unit Test Rules before any step in the Flow.

Example:

We begin in the Designer Folder with clicking Create Flow button on the Folder Actions Panel.

Then, we Name the Flow and click Create to proceed to the Flow Designer.

First, we are going to add a complex data type as a Flow Input. We select start step on the workspace and click Add New Flow Input Data. Then, we Name the Variable and define its type of Account.

Next, we connect Start Step to the End Step in our Flow and click Unit Test link on the Top Panel of the Flow Designer.

We Name our Unit Test and press Account Flow Input Data picker.

Then, we pick an existing Account and click Ok.

Next, we are going to build a Rule for this Unit Test.

When Rule Designer opens we click Add New Rule Step.

Because we have a complex Account Flow Input Data, we can see an Account input and use in the Rule Designer. Moreover, we are able to write a Rule to evaluate any desirable field of the Complex Data Type. In this Example we are going to pick Email Address field from the Account input.

Then, we select Contains verb…

Finally, we check if Email Address contains Constant ‘admin’ value which will fail our Unit Test because for this Unit Test we have selected an Account that has user@decisions.com Email Address.

Our Rule is completed. We can save it and close Rule Designer.

Next, we Save our Unit Test…

In the Flow Unit Tests window we can click Run All to run a Unit Test that we have just created.

And our Unit Test fails…

Next, we are going to update our Flow. We Add New Flow Output at the End Step by simply picking Account Flow Input Data.

Then, we click Unit Test. In the Flow Unit Tests window we click Create New, Name Test, and pick the same Account that we picked for the first Unit Test. Next, we start building our Rule.

In the Rule Designer we start building a Rule Step by picking Email Address field from the Outcome_Done_Account Data.

Then, we build our Rule in the same manner we did for the first Unit Test in this tutorial. When finished, we can save the Rule and close Rule Designer.

Back in the Flow Unit Tests window we Save second Unit Test and Run All tests.

As we expected, both Unit Tests fail…

Next, we are going to see the advantages of 3.5 Decisions Unit Test utility compared to 3.2 Decisions Unit Test. We are going to update our Flow with the Step that will change our Complex Data Flow Input (Account). Between Start and End Steps in our Flow we add UpdateAccount Step from Integrations > All Integrations > Internal Services > Account Service category.

Then, we select UpdateAccount Step on the workspace and click Show Mapping Editor.

In the Mapping Editor we pick Build Data Mapping type for the account input into the Step.

Then, we map all data from the Account Flow Input to the account UpdateAccount fields except EmailAddress. For the EmailAddress field we Constantly change it to userAdmin@decisions.com. Save and close Mapping Editor when finished.

Back in the Flow Designer we click Unit Test and in the Flow Unit Tests window we Run All our saved Unit Tests.

This time the First Test fails and the Second Test passes. Even though we Output the same Account, it was changed in the Flow and satisfies conditions of the second Unit Test.

Next, we are going to create similar Testing case in Decisions 3.2 and see how it differs. We created a simple Flow that has acc (Account) Flow Input and we just pick this Data for the Flow Output on the End Step.

Then, we click Debug Flow and it asks us to create a Unit Test because our Flow has undefined Flow Input Data. We Name the Unit Test, Expect it to Pass and using Input and Output Data pickers…

We pick the same Account and Save Unit Test.

Next, in Flow Unit Tests window we click Run All…

Obviously, our Test passes because we picked the same Account for the Input and Output.

Then, we update our Flow with UpdateAccount Step to change FirstName field of the Flow Input Account.

Then, we click Debug Flow and in the Flow Unit Tests window we click Run All to run our saved Unit Test.

The Test passes again even with the changes made to our Account because we were not able to apply the Rule to check a particular Account’s field.

Next, back in Decisions 3.5 we are going to look at the case where we have a Form in our Flow and need to run Unit Tests. We add Show Form step from Favorites category after UpdateAccount in our Flow.

In the resulting window we Name our Form and click Create to proceed to the Form Designer.

Our Form has a TextBox and a Button. When finished designing our Form, we can save it and close Form Designer.

Back in the Flow Designer we define a Constant Input for the TextBox on the Form.

Then, we connect Form Step to the End Step in our Flow and click Unit Test.

In Flow Unit Tests window we click Run All…

First Unit Test passes because our Account’s Email Address was changed in the previous Run and now it satisfies the conditions of the first Unit Test. But second Unit Test fails… It fails because our Unit Test cannot complete the Form and get to the End Step. As a result, all Unit Tests that perform checks after the Form Step will fail.

Next, we are going to demonstrate how to fix this. On the workspace we select our Form Step. If we scroll down the Step Settings, we should see Testing and Simulation options. This set of options available for each step in Decisions. We expand Testing and Simulation category to check what options we get here…

Handle In Debugger:

• OnlyOnce (output Debug Info once: if we have a step in a loop the info about first step execution only shown)
• EveryTime (output Debug info for each step run in current Flow execution)
• Never (Debug info for the step will not be shown in Debugger)
• Default (set in System > Settings > Designer Studio Settings > Flow Debug Default)

Next, in Use Simulation Behavior we can set Simulation Behavior for this step InDebugger, InProduction, and InUnitTests. For this example we need to set Simulation Behavior for InUnitTests. After we check InUnitTests check-box we need to define Simulation Data because our Form has an input TextBox that needs to be defined for Simulation.

We simply set it to some Constant value. In Simulation Selected Path we can set an Outcome for the step if it is in Simulation mode. For instance, if our Form had two Action Buttons we would have been able to select which Outcome Path our Flow takes if the Form Step in Simulation mode.

 

Then, we click Unit Test and in the Flow Unit Tests window Run All…

This time both Tests pass because Unit Test utility was able to simulate Form Step.

Another powerful feature of Unit Test utility is that we can run our custom Rules before any Step in our Flow. This means that we can check what we should expect at certain points of Flow execution. To use this feature we need to select a Step on the workspace, in the Step options check Run Unit Test Rule check-box. Then we will see an option to build or edit a Rule.

In this example we build a simple Rule that checks if the Output from UpdateAccount step is null. Then, we save the Rule and close Rule Designer.

Back in the Flow Designer we click Unit Test. In the resulting window we click Run All.

Both Unit Tests fail because Unit Test for our Form Step failed.

 

 

 

 

 

 

Additional Resources

• Creating Your First Flow
• Using the Mapping Editor
• Creating your First Rule
• Unit Tests Overview (Simple Flow)
• Integrating Decisions with External Oracle Database