29.04.2016 | Janine Eichler (guest author) | comment icon 0 Comment

Testing your rules without pain

In my current project we decided to use JBoss Drools 6, mainly for mapping data. It turned out to come in quite handy. However our team committed to develop test-driven. Hence we can’t just ignore the rules – they are part of our code base. So, there’s no way out – we have to test the rules (or the other way round: we write tests and implement the rules).

I’d like to focus on unit tests in this post. Why not integration tests? Well, because that’s straight forward. For instance for JEE with Arquillian, just add the desired resources, inject your component, that’s it. With Spring it’s pretty much the same. Just run the test in the proper application context, autowire your component and you’re good to go.

For unit tests this can’t be done without getting your hands dirty. When first writing a unit test for a simple rule (a slightly more complex rule than the typical “Hello World”) I was astonished how clumsy and cumbersome it was. Listing 1 shows what I’ve done (the code is of course reduced):

Easy, eh? Even if we’d skipped the reading of the result messages of the KieBuilder the overhead is still huge given the fact that we just want to test a rule. Once maybe it’s ok, however, we developers, tend to be lazy and want everything to be easy to use. Therefore I wrote a little library containing a JUnit-Runner that hides all that boiler plate code and just lets you focus on the important thing: testing the rules.

Here’s what you need to do:

1. Add the library to your dependencies:

2. Add the runner and an annotation to your test class:

3. Inject a Drools session into the test class and start testing 🙂

So far, so good. The library, of course, has just some pretty basic support for drools. The DroolsSession itself doesn’t expose that much because I simply had no need to in my Drools-projects so far. Feel free to contribute or raise an issue for that – I’d be happy in both cases.


A glimpse under the hood

Now that we’ve had a look on how testing Drools rules can be simplified with a small library, I’d now like to take you to a short tour through the library itself.

The entry points are, of course, the annotations:

This is probably more than familiar to you. You simply define the runner for that test class. That DroolsJunitRunner is responsible for initializing the test and injecting the Drools session into the test.

@DroolsFiles(ruleFiles = “aRule.drl”)
That annotation defines the rule files to be included in your knowledge session (KieSession or KieStatelessSession).

How is that stuff wired? The DroolsJUnitRunner creates a test instance which is passed to the DroolsInjector’s initDrools()-method. Then nothing special happens:

I create the wrapper-class which holds the actual Drools session. The annotation processor then just puts the Drools session into the annotated field using a little reflection:

That’s it

drools junit

Leave a Comment