Sparked by a recent post by Phil Haacked (of ASP.NET MVC fame), a lively debate on the merits of Test-Driven Design - and in particular a publication by Dr. Hakan Erdogmus at the Institute for Information Technology in Ottawa titled On the Effectiveness of Test-first Approach to Programming ensued, as Jacob Proffitt dissected said report in detail over on his blog a few days ago. I highly recommend reading both the paper, Phil and Jacobs posts (as well as the comments posted on them by various people), as there are some interesting points made on both sides of the fence.
One thing I've always felt TDD is a catalyst for, which the paper seems to miss out on, is increasing the quality of code design and better highlighting what code really needs to be written. By writing code that uses an API before writing the API itself, you're led to writing the API from the outside in, thinking more about its exterior design and what really needs to go into it. If you start from the core and work your way outwards, meeting the required public interface is more a hit and miss process which easily leads to a bloated API that does more than it really needs to, exposing functionality or extension points that will never be used.
Whether this (unproven?) benefit is enough to tip the balance in favor of TDD I'm not sure, but as the debate rages on we can all at least agree on one thing - writing unit tests one way or another is better than not testing at all :)
