Drools!

Drools, or JBoss Rules is an open source framework that facilitates an easy maintenance of rules. And it comes with a feature called decision matrices which I quite perticularly like. Makes it easy. The best thing is that a decision matrix could be a MS Excel sheet, which means I can have a 2D expression of conditions. It also means that this matrix can be maintained by business analysts and can be created at the time of requirements gathering, instead of being developed by coders at the time of implementation. Gives you a bit of a head start!

Do I use Drools everywhere I have rules? No way! I use it at places that have a high density of if-else kind of statements, otherwise I prefer to use plain old if-elses. The reason is simple, drools does add an overhead, although minimal, of its own. Plus, the logic is decentralised and developers typically have an apprehension dealing with a "different" technology. Anyways, the simplicity achieved via decision matrices scores much higher.

I used Drools recently for a e-commerce function, we had to provide a list of products that a customer could buy based on a number of factors. Had we implemented in the classical if-else manner, it would have been a nightmare to find issues and fix, but decision matrices ensured that we had minimal bugs and any found were easily fixed.

Its super cool, if you haven't tried it yet, I strongly recommend you work out some time soon :-)

Need for Stub!

Do you have many external system interactions? Too many third parties? Do they provide easy interfaces for testing different scenarios in your application? Do I hear a resounding no? :-)

We have an application that depends on 30+ external systems that either do not provide test interfaces, or the ones that are provided, are quite primitive. That's quite bad because we can not effectively test our application and most of the logic goes untested to production. Take a guess... yes we have a large number of issues on production :-(

When we started writing the application, we decided we needed stubs, i.e. programs that will block our actual interaction with the third party and give us some response back. The problem with this approach is that you never look at the request! So we scratched our heads and we thought the following were the options:

1. Dumb stubs: Any request, you get a fixed response. No good unless you don't have any logic around the response that comes back.

2. Wise stubs: Based on the request coming in, validate it, point out errors, and prepare a response. The response could be different for different requests so can enable a wider scale of testing.

3. Simulators: Enhance the wise stubs so that they maintain a state of requests as well (may be across stubs if required). So if you have a stub for withdraw money and another to deposit, both should update a "balance" which should be visible to both.

In all of these cases, another dimension is that you could have stubs that sit in the same layer of application as the end point connectors, or you could have them available as services over protocols similar to how it will be on live.

I suggest building wise stubs that are available as services. Simulators are too much of a pain to write so unless you need them desperately, avoid them.

This is what we did recently: we used Mule. How does Mule help me ? Greatly!

1. Mule provides me with a central way of interacting with all different stubs.

2. We now have a common framework for designing and implementing stubs.

3. Most of the protocols are supported out of the box (we had to write a custom handler for Telnet though) so its kind of plug-and-play.

4. It can be easily run on a seperate JVM and can be deployed anywhere in the system.

5. I can easily build delays in the responses so that performance testing can see real life type responses.

6. And its easy!

Unit Testing with HSQL

Ever wondered how you could increase the speed of execution of test cases that run against a database? Or how you could unit test without impacting the data in your database? The obvious answer to the latter is to use a seperate database schema, but speed? How about an in-memory database? See, now we are talking!

HSQL provides a means of running an in-memory all Java RDBMS, so everything runs in the heap. All you need to do is to include the JARs from HSQL website (no I wont give a link here, please use internet search :-) ) into the JUnit execution classpath, configure the datasource as jdbc:hsqldb:mem:mydatabase?shutdown=true. If you use Hibernate in your application, you can use the SchemaExport feature (with Spring over Hibernate, use session factory bean to create database schema) to create the tables et al in the database as well. Bingo, you have a new and shinny blank database schema in the Java heap to run tests against.

I had to write my own Oracle specific functions and register them with HSQL because people had used them in HQLs :-(. Anyways, its not difficult and all you need to do is to have a class with static methods that implement the required feature and run "CREATE ALIAS" SQL queries against the database. That's it, easy peasy!

Using HSQL, I was able to bring down test execution time from 1.5 hrs to 20 mins.