let x=x

In Emergent Design Scott L. Bain dedicates a chapter to Paying attention to Disciplines: Unit testing. To an experienced agilist this may seem a little basic: of course the discipline of unit testing pays dividends! But I think that we agilists forget sometimes that there are still many programmers – or their management – who don’t value the investment needed to get the extensive returns of unit testing and test driven development (let alone test driven design).

I have found too many code bases over the years, with bolted-on, after the fact tests, plagued by spaghetti code and strongly coupled components to be that naive about unit tests. Sure people pay lip-service to testing, but I think many programmers haven’t yet found the value of test driven design in their professional practice. I know enough that I come across this situation frequently. “Oh I’ll do the tests later”, “I don’t have time to write tests, I have to write code!”, etc. Heck, I am sometimes still guilty of it myself. Here’s some rolled-gold reasons Bain gives to pay particular attention to the discipline of unit testing in a test-first scenario:

• It reduces bugging time.
• It makes the development process more predictable – finding bugs often exhibits non-linear unpredictability.
• It encourages appropriate coupling, ensures cohesiveness, and reduces redundancy.
• It makes you think about your code in more depth.

I must say, even when confronted with an existing code base that has little to no unit testing, it’s always advantageous to start writing the tests before you start fooling around too much with the code base. It will help you discover the design weaknesses.

Another point I have to make about unit testing, is that whenever I need to evaluate a new technology,  I now use the ability to utilise test-driven methodologies as an important criteria. Especially if that technology is supposed to be a productivity-booster for programmers. If I can’t write the tests first, then I just know the tool, or technology, is going to produce less than optimum results – how can it make any programmer more productive if it removes the ability to write code until the tests pass? And if I can’t write any tests – that is it has no test framework either built-in or freely available, then I just know the tool sucks, and is to be actively avoided and recommended against. I’m especially suspicious of technology such BPEL frameworks and other frameworks designed to provide “programmer-less programming” (but that will have to wait for another day).