I’m a fan of automated software testing. If you’re not providing proof that your code works as part of your deliverable you’re not really doing software development, you’re just having a bit of fun on the side. If you hit up google for Test Driven Development you’ll find lots of information about what it is, why it’s good and so forth. The focus is on the process of testing, but there’s not much on the effects of good testing on your system. The wikipedia page only makes passing reference to the effect on design. I like to think of TDD more in terms of Test Driven Design than development.

For me this brings out one of the primary benefits. By focusing on designing the system to be testable up front a better design emerges almost by magic. You get less coupling, tighter cohesion, lower complexity. Any code metrics you care to choose will all come out better with good testable code.

Another benefit that often gets overlooked is the way tests document the developer’s intent. Good tests read as a description of the functionality.

A new developer starting on a project can find it difficult to get to grips with the ‘meat’ of the system. I always point new people at key tests and say, run these tests in the debugger and see what’s going on. This is much more interesting and informative than wading through stale, dry design documents.