What is unit testing?

A good enterprise computer system should be built as if it was made of Lego bricks. Your rules are only a piece of the puzzle. You’ll need to go back to the Lego box to get pieces that talk to the database, make web pages, talk to other systems that you may have in your company (or organization), and so on. Just as Lego bricks can be taken apart and put together in many different ways, the components in a well-designed system should be reusable in many different systems.

Before you use any of these components (or ‘bricks’) in your system, you will want to be sure that they work. For Lego bricks this is easy—you can just make sure that none of the studs are broken. For components this is a bit harder—often, you can neither see them, nor do you have any idea whether their inputs and outputs are correct. Unit testing makes sure that all of the component pieces of your application work, before you even assemble them.

You can unit test manually, but just like FIT requirements testing, you’re going to ‘forget’ to do it sooner or later. Fortunately, there is a tool to automate your unit tests known as Junit (for Java; there are also versions for many other languages, such as .Net). Like Drools and FIT, Junit is open source. Therefore, we can use it on our project without much difficulty. Junit is integrated into the JBoss IDE and is also pretty much an industry standard, so it’s easy to find more information on it. A good starting point is the project’s home page at http://www.Junit.org.

The following points can help you to decide when to use unit testing, and when to use the other forms of testing that we talked about:

• If you’re most comfortable using Guvnor, then use the test scenarios within Guvnor. As you’ll see shortly, they’re very close to unit tests.
• If the majority of your work involves detailing and signing off against the requirement documents, then you should consider using FIT for Rules.
• If you’re most comfortable using Java, or some other programming language, then you’re probably using (J)unit tests already—and we can apply these unit tests to rule testing.

In reality, your testing is likely to be a mix of two or three of these options.

Why unit test?

An important point to note is that you’ve already carried out unit testing in the rules that we wrote earlier. OK, it was manual unit testing, but we still checked that our block of rules produced the outcome that we expected. All we’re talking about here is automating the process.

Unit testing also has the advantage of documenting the code because it gives a working example of how to call the rules. It also makes your rules and code more reusable. You’ve just proved (in your unit test) that you can call your code on a standalone basis, which is an important first step for somebody else to be able to use it again in the future.

You do want your rules to be reused, don’t you?

Unit testing the Chocolate Shipments sample

As luck would have it, our Chocolate Shipments example also contains a unit test. This is called DroolsUnitTest.java, and it can be found in the test/java/net/firstpartners/chap7 folder.

Running the Junit test is similar to running the samples. In the JBoss IDE Navigator or package explorer, we select DroolsUnitTest.java, right-click on it, and then select Run as | Junit test from the shortcut menu.

All being well, you should see some messages appear on the console. We’re going to ignore the console messages; after all, we’re meant to be automating our testing, not manually reading the console. The really interesting bit should appear in the IDE— the Junit test result, similar to the screenshot shown below. If everything is OK, we should see the green bar displayed—success!

We’ve run only one unit test, so the output is fairly simple. From top to bottom we have: the time it took to run the test; the number of errors and failures (both zero—we’ll explain the difference shortly, but having none of them is a good thing), the green bar (success!), and a summary of the unit tests that we’ve just run (DroolsUnitTest).

If you were running this test prior to deploying to production, all you need to know is that the green bar means that everything is working as intended. It’s a lot easier than inspecting the code line by line.

However, as this is the first time that we’re using a unit test, we’re going to step through the tests line by line. A lot of our Junit test is similar to MultipleRulesExample.java. For example, the unit test uses the same RuleRunner file to load and call the rules. In addition, the Junit test also has some automated checks (asserts) that give us the green bar when they pass, which we saw in the previous screenshot.