Designing for testability

I've investigated a bewildering number of TDD tools and integrated some into an existing application that I inherited. It's been a great learning experience. One of the tools that I evaluated at was FitNesse. It looks fantastic and I wrote a bunch of test tests (great English there!) but ultimately I did not integrate it into the application. I must admit that I was conscious of making things excessively difficulty for the poor schmuck who will have to support the application when I've moved onto something new and shiny. But the deciding issue was that I was not able to find a piece of the application where I could get significant value from using FitNesse as opposed to standard unit tests.

That changed today when I started to look at some issues with our calculation engine. It is crying out for FitNesse tests. Our user community are much better placed to know what results to expect compared to the developers. But the difficulty of writing tests (of any type) in the calculation engine is phenomenal due to large number of setup steps and multiple layers that must be traversed in order to perform a calculation.

One of the most powerful lessons that I have learned is that TDD retrofitting is horribly painful if the application was not designed with TDD in mind. A lack of interfaces is the obvious crime and because no form of Dependency Injection is used (everything is hardwired together) it is impossible to test discrete pieces of functionality. Without a comprehensive suite of tests I don't want to risk a major refactoring exercise and that is going to leave FitNesse on the sidelines for this project which is a crying shame.