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!