orangepips

It's been said, "A foolish consistency is the hobgoblin of little minds." And, in my experience TDD can easily slide into this fallacy. So it gladens me to see someone like Cédric Beust, creator of the TestNG unit testing framework, call out the TDD zealots. In addition he also offers some heuristics that I think really capture the essence of how unit testing should be approached.

To wit, I tried introducting unit testing at my workplace and ran into this very problem. But, some background first:

The product I work on is closing in on a decade of development. And stuff that was almost 10 years ago, which is still around and used, has UI, database I/O and business logic all intertwined. Very much a Model 1 architecture. But, before you start ranting about bad design practices and MVC and so forth, know the product works, and makes money. And, it started out in Coldfusion 4. So objects were not an option and Fusebox was nascent at best.

With a codebase like this, you cannot just flip a switch and make it unit testable. Anyone who proclaims changes to said code must be unit testable is not living in reality. It's possible to move in that direction, but if it took you years to create that codebase, don't expect it to take days, weeks or months to get to a unit testable state. These things are intertwined and must be broken apart carefully with planning and coordination with testing.

Programming is fundamentally just as much a social and technical problem. Attempting to impose a command and control structure on programmers == bad idea. But the appeal of implementing a Good Idea as the Only Idea can be overwhelming.  This was definitely the case for my environment, where instead of focusing on the notion of having good unit tests, TDD ruled the day and it became you must have unit tests before you code.

This crashed and burned rather quickly as developers pushed back.

Now personally I write unit tests for my code that does not involve database I/O or UI. Where I find the configuring the dependencies, even through injection, outweigh the benefits of unit testing. But as a result, most code that I write separates these aspects out leaving everything else in a unit testable state.

What I do find is that sometimes unit tests makes maintenance easier. But, that sometimes if the change is large, I need to throw out the old tests. Maybe I write new tests or maybe I don't. It just depends on complexity and time. And, for TDD adherents I am sure this is probaby heresay.