Thursday, December 06, 2007

Testing rules - introduction

Quite some time ago, I created the fit-for-rules project, which was built using the FIT framework (Framework for Integrated Tests). I was quite a fan of fit - however for reasons unknown it has not yet taken off in the mainstream (perhaps its just too strange, I think its brilliant, but then I like egg nogg lattes at Christmas - no idea why, its not something I would normally like at all).

Recently we have been working on an integrated testing tool to encourage people to write tests for rules the TDD people do for code. This tool, still doesn't have a name, so feel free to suggest some names. In terms of the tool itself, I spent some time looking into BDD (behavioral driven development - not the disease), and tried to adopt the BDD nomclamenture.

So, the basic test item is a Scenario. A scenario is essentially a sequence of data followed by expectations (ie in a given scenario, expect things). Expectations can be data, or rules firing etc.

Its not that different to a rule:

Given some data -> Then fire the rules -> Expect some results -> Modify some data -> Fire the rules -> Expect some results.

You may only want one given/expect cycle, but as rule session are (can be) stateful, this will allow it. Well a picture is worth a thousand words:

You can see it looks not unlike the guided editor. You set up facts, and then simulate rules firing (actually they do fire, unless you tell it to not fire certain rules). You can then check the data and rules after the fact (rinse, repeat). These tests are just as important as the rules, and will be stored as such.



Simulating a date is optional, but handy as often rules are dependent on time.

Suggestions for a name for this?

6 comments:

  1. It's name could be "rules sense"

    ReplyDelete
  2. So this is integrated into the BRMS or a standalone app? Either way it is a good idea.

    I actually had this similar idea a few weeks ago, and to maybe expand on this principle:

    1) A requirement for this to run, as rules are saved into the BRMS. Maybe have a policy to require at least 1 true and false rule, or something configurable to enforce TDD/BDD.

    2) Integrated or not there should be a way to scan the rulebase for coverage. An easy way to see how many tests do I have to fire against my rules. Where should I add tests. This is nice for legacy rulebases.

    3) Expose these tests to extrenal API so they could be run similar to Junit for external QA testing later on.

    Either way, this is a great direction to take Drools. Glad to see this going on.

    As far a name I would offer something with Drools as part of the name and Testing..

    Drools Automation Testing (DAT)
    Drools Integration For Testing (DIFT)
    DRools Integration Framework for Test (DRIFT)

    DRools Automation Framework for Testing (DRAFT)

    Something along those lines, but the function is more important than the name.

    ReplyDelete
  3. Michael - yeah integrated with the BRMS to start with. The code to run the tests is part of drools-compiler - being able to run as part of ant/junit is also a nice idea, once it settles down, we will document the api and the test language, and then it can be used how you wish. The idea is also to have it in the IDE (but BRMS first).

    ReplyDelete
  4. Michael, I'm very curious as to if there is still any development with Fit-for-Rules. I could not find any example of it in action or any documentation any more than the link from Drool's documentation page.

    ReplyDelete
  5. Hi there,

    why can I find the latest information about "testing rules for drools"?

    ReplyDelete
  6. This is an old blog, you should try the user mailing list. There is also a fair bit in the latest manuals now.

    http://www.jboss.org/drools/lists.html
    http://www.jboss.org/drools/documentation.html

    ReplyDelete