Introduction

Continuing the theme of IBM Business Automation Manager Open Editions (BAMOE) v9, the latest version 9.2.0 contains improvements and functionality to support workflow, business rule, and automation deployments as microservices. In this blog post, some of the latest updates to the Test Scenario Editor will be discussed and demonstrated.

Background

Verifying the correctness of any code before deployment is of major importance for applications, after all, receiving that early morning call that the app is broken is never at the top of anyone’s list. Testing also provides a safety net for refactoring and improving. This applies as well to any business rule or DMN model. BAMOE includes a Test Scenario editor in both version 8 and version 9. The Test Scenario Editor allows validation of rules by creating GIVEN conditions and EXPECTED results, very similar to a unit test.

In BAMOE 9.2.0, a new version of the Test Scenario Editor has been released. It contains similar functionality as the older version and some additional enhancements. It has also been reworked on top of a modern technology stack.

Why a new editor

Beginning with v9 of BAMOE the tooling strategy and technology stack changed to embrace modern frameworks. The previous versions of the tooling were based on technologies that are no longer being maintained: Errai (which is based on GWT), Appformer, and Lienzo. As a result, implementing new features and ongoing maintenance, including bug fixes and CVE resolution, requires a lot of effort.  They have served well for the classic editors; however, the rest of the industry has moved on. Going forward, the new tooling will be based on TypeScript and React. Using more modern technologies allows tooling progress to happen faster, will allow for a more consolidated codebase, the same code will run in VS Code and Canvas, and will also enable the team to grow using technologies more common in the industry.

Features of the New Test Scenario Editor

The Test Scenario Editor allows for testing of DMN logic. Just like any other unit test, testing decision logic at build time ensures everything works the way it should. The new editor allows you to create a new scenario by choosing an existing DMN file and automatically populating the types and field names. Of course, the editor still allows for modifying or adding or removing fields and specifying the data types for those fields.

The editor contains help, or a “cheat sheet,” on the far right of the editor, and a background tab. The Background tab allows for a field to be declared once and the value reused on each row.  Specifying a value for the same field in a row will override the value from the background for that row. This is particularly useful in a large decision matrix with repeated values.

To execute these tests during a build, a Java class with a Junit runner of type org.kogito.scenariosimulation.runner.KogitoJunitActivator[YA2] [JP3]  must be added in the test/java directory[YA4] [YA5] . Note, for the upcoming 9.2.1 release, this will change, and a new annotation will be used, please refer to the documentation. The class doesn’t need to have any content, but the KogitoJunitActivator runner must be referenced. This class will gather all the scesim files and run them during the testing phase of the build. The editor has a toggle to exclude a scesim file from testing execution. The following dependency must also be added to the project:[YA6] 

<dependency>

  <groupId>org.kie.kogito</groupId>

  <artifactId>kogito-scenario-simulation</artifactId>

  <scope>test</scope>

</dependency>

Using the Scenario Editor

Below is a very basic DMN example. Although it is trivial, it easily demonstrates the usage.

This DMN model simply checks a person’s age with that of an adult, 18. If the person is 18 or older, it returns true, otherwise the return is false. Nothing complicated here.

Within VS Code, using the BAMOE Developer Tools extension (available at https://marketplace.visualstudio.com/items?itemName=IBM.bamoe-developer-tools), create a new scesim file in the test/resources directory.

The editor will ask what the asset type is (Rule DRL or Decision DMN). Currently, the new editor cannot create DRL based scenarios. Upon selecting DMN, the editor presents a list of DMN files in the project. Selecting a DMN file will give the option to auto populate the fields and data types.

Fill out the different scenarios for testing and the expected outcomes. The scenario is now ready to be run along with any other tests in the project using the standard Apache Maven testing: mvn clean test

Conclusion

The scenario test editor allows for more confidence in application rules during development and deployment. It provides a graphical way to verify the logic is correct in decision-based applications. Both the classic editor and new editor are available in 9.2.0 and will continue to be available while the new editor reaches feature maturity. Look forward to more releases with even more features!