2

Brief

I'm looking to write unit tests in JUnit to check individual drools rules. A unit test should be simple to write and fast to run. If the unit tests are slow then developers will avoid running them and the build will become excessively slow. With that in mind I'm trying to figure out the best (fastest to execute and easiest to write) method of writing these unit tests.

First attempt

The first option I tried was to create the KnowledgeBase as a static class attribute and initialized on one .drl file. Each test then creates a new session in the @Before method. This was based on the code examples in the Drools JBoss rules developer guide.

I've seen a second option that tidies this up a bit by creating some annotations to abstract the initialization code but it's basically the same approach.

I noticed that this basic unit test on one .drl file was taking a couple of seconds to run. This isn't too bad with one unit test but once it's scaled up I can see it being a problem. I did some reading and found that the KnowledgeBase is expensive to create, whereas the session is cheap. This is why the examples have the KnowledgeBase as static so it's created only once, however, with multiple unit test classes it will potentially be created many times.

Alternative

The alternative I tried is to create a singleton KnowledgeBase that will load all .drl files. This will be done once globally for the test suite and then autowired into each test class. I used a spring @Configuration class and defined the KnowledgeBase as an @Bean. I now find that the KnowledgeBase takes 2 seconds (but runs only once), the session creation takes about 0.2 seconds and the test itself takes no time at all.

It seems as if the spring approach may scale better but I'm not sure if I will get other problems with testing a single rule but using a KnowledgeBase initialized on all files? I'm using an AgendaFilter to target the specific rule I want to test. Also I've searched online quite a bit and haven't found anybody else doing it this way.

Summary

What will be the most scalable way of writing these tests? Thanks

Ben Thurley
  • 6,943
  • 4
  • 31
  • 54

1 Answers1

2

This is a very nice collection of experiences. Let me contribute some ideas.

If you have a scenario where a large number of rules is essential to test the outcome because rules vie with each other, you should create the KieBase containing all and serialize it, once. For individual tests, either derive a session from it for each test, inserting facts and firing all rules, or, alternatively, derive the session up front, and run tests, clearing the session (!), inserting facts and firing all rules.

For testing a single rule or a small (<10) set of rules, compiling the DRL from scratch for each set of tests may be tolerable, especially when you adopt the strategy to reuse the session (!) by clearing Working Memory between individual tests.

Some consideration should also be given to rule design. Excessive iterative algorithms should not be implemented in DRL by hook or by crook; using a DRL function or some (static) Java method may be far superior. And testing such as these is much easier.

Also, following established rule design patterns helps a lot. Google "Design Patterns in Production Systems".

laune
  • 31,114
  • 3
  • 29
  • 42
  • Thanks for your answer. I've discovered we have some declared types and functions that are shared between rules. These are declared in a separate file so it makes sense to go for my spring approach where we load all files. Furthermore we have a rule initializing the working memory that does things like instantiate pseudo-enumerated types. As we get into more complex rules then this rule will need to have fired. I'm wondering now about the pros and cons of a cached session that is cleared vs a new session each time. I don't believe you can revert a session to a previous state. – Ben Thurley Nov 23 '17 at 15:24
  • ad "revert to previous state:" It's possible, but generally only to a state with empty Working Memory. Retracting everything is a one-liner, and should be pretty fast. – laune Nov 23 '17 at 20:46