Unit tests are (generally) very useful

This post from a few days ago, which argues that unit tests are not useful, has generated a spirited debate, and I wanted to chime in.

Without a doubt, Unit tests are (generally) extremely useful.   I realize that one can find examples of trivial code or toy problems for which unit tests wouldn't provide much usefulness, but such pedantic arguments aren't very helpful.

The author of the post above claims that unit testing isn't useful because it doesn't find bugs.  Many commentors have already pointed out the fallacy of this argument, namely that unit tests aren't supposed to find bugs, they are supposed to prevent them.  The author then backtracks saying he meant pre-release bugs, but his examples of activities that he feels find bugs more effectively are almost all post-release activities (user reports, monitoring and logging).  Even load testing is post-release in my opinion, because I consider code I write to be production ready whenever I release it to QA.

This is one of the major benefits I personally gain from unit testing: confidence.  Having a comprehensive suite of unit tests allows me to both code new functionality and (as importantly) refactor existing functionality and drastically reduce the risk that I will unwittingly break pieces of the system.  I really can't imagine doing continuous refactoring without unit testing.  I can, however, imagine not doing any refactoring at all, because I have lived in that particular circle of hell and don't wish to visit again anytime soon.  Building up such technical debt is the usual destination for shops that don't do automated unit testing.

If you're really good, test driven development provides a confident basis for both code's design and implementation.  Forcing oneself to stop and think of the design and interface to a piece of functionality before coding its internals leads to much better organized software and a more solid design overall.

This whole debate highlights a major perspective problem I've seen in other software shops in the past: the "code and fix" mentality.  This attitude (well represented in the above blog post) says that the programmer's job is to simply write code (and maybe do some design work every now and then).  This narrow view of software development is prevalent in the industry and is the reason behind the generally low quality of much software being released.  If you're in management and hearing this argument from your techology team, you should take a look at how much you're spending on that army of QA staff, then look at the overall quality of your system (measured by number of defects in production).  Having done this,  it becomes be pretty clear whether or not to reject such arguments with a vengeance.