Invoking Greek goddesses to get your test suite in order

Posted on 2008-06-23 08:30:00.0 by Tim Fox [ View original post ]

One thing we're really proud of in JBoss Messaging is our testing. Very soon our unit test suite will be giving close to 100% coverage of our code, and, what's more it runs very fast.

Having a solid unit test suite that runs like lightning is critical for fast effective refactoring of the code.

Long running test suites are a bad test smell. More than likely you've experienced this yourself (I certainly have), you're working on a project and it takes about three hours to run the test suite. So before every commit, you have to wait three hours to see if your changes have broken anything. Or even worse, the test suite takes so long that it's not practical to run it every time you commit, so developers are constantly breaking each others code and progress slows to a crawl. Sounds familiar?

This kind of situation is very expensive to fix retrospectively, and comes down to poor testing techniques from the offset, and too much reliance on integration testing. Familiar bad test smells here include having to start and stop the entire server on each test, usage of Thread.sleep, and start and restart the third party components e.g. databases, jgroups... All these times add up.

In JBM 2.0 we're making sure all our classes are thoroughly unit tested. We use mock or fake objects where appropriate, these nullifies any startup/shutdown times associated with starting any real implementations of the third party components. Then we have a smaller number of integration tests which tests how the objects interact together.

One other thing we've done here is to invoke the law of Demeter

This basically means that you're avoiding doing things like this in your code:

int id = connectionFactory.getConnection().getSession().getConsumer().getID();

Avoiding ugly stuff like the above does two things:

1) Makes your code more maintainable and simpler to refactor since each component does not have such a deep knowledge of other components

2) Make writing mocks a lot easier, since you're not constantly having to tell the mock to expect these nasty chains of invocations.

---