I am happy to write my first post about a topic in Visual Rules projects that is both, the most important thing and often the most neglected one. I am writing about rule testing – or better: creating sustainable tests. I see that especially in the beginning of projects loads of rule tests are created. Which is good. The problem with this schedule however is that during the course of rule development maintaining your tests becomes more time-consuming.

If you have a lot of rule tests structured badly, (regression) testing becomes inconvenient and project participants quickly lose motivation in testing. This post is about an approach lent from software programming, called unit testing. I will show you, how it can be adapted to VR projects and improve the maintainability and scalability of tests. But first it is important to understand, why tests can become a pain if wrongly organized and rule modelers get sloppy with testing.

Rule tests want to be taken care of

Every test case has a direct dependency to a business rule. If the rule´s inputs or outputs change, all test cases need to be adapted. Same goes for the object model. If, e.g., an Integer is converted to a String, you will have to add lots of quotes throughout your rule project.

Refactoring necessary if Integer attribute became a String

Specifiying test inputs can be annoying

Depending on your strictness when defining your inputs and outputs (a very important topic by the way, but that is another story), you have to fill in more or less information. Which ones are important for the test? Filling out all the fields is too time consuming, entering just some might not be enough.

For complex objects, its hard to tell, which parts are needed for the test

Unclear responsibilities

Simple question: Who maintains the tests? Depending on the organization of the project, it can be a modeler or a dedicated tester. A tester would not get permission to change the rule. But if the test is attached to the rule, it would need different permissions for the rule and the test. With modeler and tester in one person, the responsibility issue remains. If global changes of Modeler_A affect rule domains of Modeler_B, Modeler_A would have to change Modeler_B´s rules and tests, to which he might not have permissions.

Responsibilities not clearly split up

Feel free to add points to this list. I´m sure there are more than the currently listed ones. Now, how can you set up your tests in order to eliminate those issues? The answer is surprisingly simple. I will reveal three key changes to you to perform in your rule project:

Grant tests their own project 

If testing is as important as stated by everyone, then tests deserve their own rule project. Create a test project and rebuild the package structure of your business logic. Every package in the test project needs to reuse its business logic representation. Both, the rebuild structure and the reuse is depicted below.

The test package reuses the business packages

Create testing rules

Now that you have a dedicated space for testing, you can start setting up test rules. Create a flow rule with the same name as the business rule that you want to test and add “Test” to the name. From your test rule you can now call the business rule. In the example below, the paralells between the projects are visible.

Test Rule with same name as Business Rule

Create rule tests for the testing rules

Create a rule test for your testing rule. When the rule test is executed, the testing rule calls the business rule which delivers the results.

What is the benefit of having a test rule in between? First you can mock or prepare irrelevant data that you don´t want to test. The tester does not need to provide this data in the test editor anymore. If you compare the test editor screenshot below with the one above (asking the question: “This information necessary?”), you can see, how the tester can only alter the parameters necessary for the test.

Test Rule with same name as Business Rule

Some might ask now: The whole thing of creating a new project and additional rules looks like more work. Where is the advantage? It is slightly more work to initially create the test. But loosely coupling business rules and tests eliminates the barriers for testing mentioned above:

Rule tests want to be taken care of

Now, if the data elements or types of the business rule change, it only affects your test rule. You only need to make changes there once, while your test cases can stay the same. Your test rule serves as a buffer between your test definition and your business logic. In the Integer vs. String example, you would simply use a toString() function to convert your test values before the business rule is executed.

Specifiying test inputs can be annoying

Again, the test rule serves as a buffer. No matter how many input parameters you have for your business rule, you can define different input parameters for your test rule. The discrepancy between the two inputs can be mocked, or set to null, or calculated. This can be defined in the test rule between the green start node and the business rule call. The result is a VR test, that only demands the input that can really vary between the single test cases. That makes creating test cases much easier.

Unclear responsibilities

The testing project is of the testers´ responsibility. If the Visual Rules Team Server is used, all testers get read permission for the business logic and read/write permission for the tests. The business modelers´ permissions are set just the other way around. If you don´t have dedicated testers, than the business modelers are responsible for the test project. The advantage then is, that all tests can be found in the test project. No tests can be “overseen”.

Summary: My experience

I have experienced that especially in more complex projects, this approach leads to better defined tests and simply more testing. If it´s because of the concrete advantages mentioned here, or plainly the fact, that there is a VR project in the workspace of the responsible person carrying the label “Test”, I don´t know. I would like to motivate you to try “advanced rule testing” in your projects. The exchange of conventional testing with advanced testing can be done very quickly. When doing, you will see that there are much more advantages that I will point out in a future post. But for now, I guess you´ll have plenty to try. I would be happy to read more about your experience with this approach or testing in VR projects in general. Please comment this post if you have questions or remarks!

Article by Christof Pitzer

My job at Bosch Software Innovations was to support clients in realizing Visual Rules projects. Specialized in risk rating projects, I helped Risk Analysts in Germany, Switzerland, the US and other countries with implementing business logic with Visual Rules. I left Bosch in July 2011 to take my business rules expertise to BTC AG.
more articles by this author

contact