thekua.com@rest

A long time ago (well before I was introduced to Test Driven Design [TDD]), I used to think that tests should not really affect the way that the code is written, but I’ve really changed my stance on that. It has got to a point where classes that were not driven by tests stick out like a sore thumb. I was recently working around our ManagementAgent, a singleton that obviously written to work only when deployed into a container (on instantiation, it would require configuration that would only be available from the web.xml file).

I was in a situation where we wanted to add some more configurable attributes to a specific ManagementBean (which the Management agent would add to itself on instantiation) and I seriously saw the need to refactor some of its code. Of course without tests, I knew I could not refactor in safety. I was so revolted by the situation that I was in, that I knew it was time to make the class less detestable.

Since this class was a singleton that only worked when deployed in the container, I knew it it was time its design changed. For starters, my pair and I decided to break its singleton pattern by providing a package protected constructor and an injectable configuration instead of a self-populating one. The introduction of the constructor allowed us to easily unit test it outside of the container, while the injectable configuration allowed us to more easily test the way the agent created and added a Configuration MBean that we were so desperate to refactor.

Although it has much more work to be done to make it that much less detestable, it is one step closer to being more easily unit tested and therefore much more refactorable. On a side note, there was a huge smell that indicated the classes around the ManagementAgent were so detestable when I remembered that the package it was in had been excluded from the clover target which effectively boosted the code coverage numbers. Avoid detestable classes because it will increase the cost of future change!

My pair and I were talking about getting some code coverage results for our project (it has been a while since we have the last report because of various changes in environments and breakages caused by the move to Java 5).

We managed to finally get a report and we were talking about parts of the system that came out tested. We picked a few parts at random and it was interesting to see the different styles of tests that had been written over time. I like to think that my style of tests (at least my current style) tends to be very user-centric, aimed at representing whatever use case(s) I am working on at the time. I like to make sure that the tests I write leave behind the business reason why the code that I wrote actually exists.

In contrast to my own personal style, some of the tests we inspected seemed to actually test the structure of the code that was written instead of just the business rules. Although I was glad to see the code there was actually tested, I find that these sorts of tests (probably closer to white-box testing) are not as useful as those based on business rules (think black box testing) because I find they tend to require more changes and therefore are much more resistant to refactoring. The reason for this is that if I change to code to support a similar but different business rule, can I be confident that all the previous business rules hold as well? Probably not.

I find that some of my tests might actually end up testing a little bit of code a few more times, but I have more confidence in the system that if someone decides to change the implementation, the business will still be getting the same behaviour out of the system. Oh, and I don’t think that code coverage metrics do not add value – they certainly highlight parts of the system that need testing, but like everything else in software development, actually needs just that little bit more judgment and thought to interpret the results.