Site Sections
Posts
3
Comments
3
Trackbacks
0
<< Blake Caraway and Duane Derouen Join Headspring Systems | Home | Approaches to making good software and enjoying yourself because of it: PART 1 >>
The fundamental importance of unit tests
The tide has shifted it seems from a mass of people who outright reject the need for unit testing, to those who acknowledge it as important and then do just enough to say, "Yeah, we've got testing."  This is code for, "We have a few tests here and there but we're too busy to write them most of the time"... or more likely, "I write a test every now and again, but secretly I think they're an unconscionable waste of time -- I just feel ashamed to admit as much publicly."  Whilst I might feel that these responses are unreasonable, they are at the same time extremely understandable. 

As a convert to the religion of test-driven development (once an individual who echoed the same kind of thoughts as above), I must confess that the fault of the above reasoning lies not on the shoulders of those that walk the path of the lost, but falls squarely on the believers themselves.  Too often we can recognize developers who seem destined to repeat the self-destructive habits of what is now a nearly obsolete software methodology -- implement first, test later (if you have time).  The problem is that unless said developers see first hand the benefits of a faithfully test driven software project, they have little reason to believe it's useful. 

Superficially, the idea of writing masses of unit tests seems counterproductive.  Unit testing is popularly emphasized as a means of verifying that freshly written code works as you intend it to, with the "unit" part of the term meaning you test only a method at a time.  Such an idea can easily come across as petty and self-conscious.  While this is certainly a valuable aspect of testing in general, automated unit tests provide peace of mind and immediate feedback for how all existing code responds to change. 

A developer that contributed some programming work to my current project remarked recently that it was extremely satisfying to him to come onto a sizable project, knowing next to nothing about the code as a whole, and yet feel perfectly comfortable committing major changes that would not break any existing functionality.  Why?  Because the code base was nearly 100% covered by automated tests, combined with an automated build that provided feedback on any tests that failed (and that feedback is only generally useful to ensure that a developer didn't overlook running tests on their own).  As projects grow larger and larger, it's not the testing of code you just wrote that becomes important, it's your interacting with the mass of existing code that absolutely must be verified.  Without such testing, you must be an expert on huge amounts if not all of the application (in the worst cases) to efficiently contribute.  You probably also need enormous manual testing cycles (even entire release "iterations") to rest assured that your latest launch will work at least as well as the last one.  Anyone who's worked on a typical huge enterprise application knows that even then, you're generally not going to get off that easy. 

Unit testing is really just a part, too, of the larger holistic idea of automated testing.  Unit tests, integration tests, functional tests, etc. provide the essence of automated quality control and allow for the miraculous notion of a "no defects" policy for producing software.  A joy that many have never known can arise from fully automated and fully covered testing -- on-the-spot, demo-able releases of a work in progress, even on a relatively large project.  These practices by their nature also encourage beneficial and maintainable software design decisions, like separation of concerns and dissociation of implementation and interface.  Such patterns allow for more testable, maintainable, and more easily understood code.

Without a firm belief in these values of such a degree of testing, however, not only will the performance of a developer's project(s) suffer, but so will the code itself. Without a conclusive example or experience with a successful test driven and automated application, fewer people will be inclined to walk the path of the light.
posted on Tuesday, July 22, 2008 3:51 PM Print
Comments
Gravatar
# re: The fundamental importance of unit tests
Stephen Cebula
7/22/2008 8:54 PM
Thanks for the nice post.

Another side benefit of unit tests is that they provide living documentation. If the APIs change, for example, then the unit tests won't compile. If you are in an agile development shop, maintaining system documentation might not be at the top of your priority list.

Another challenge is working with code that has little or no unit tests. Michael Feather's book, Working Effectively with Legacy Code, provides some useful tips on tackling this situation.

Post Comment

Title *
Name *
Email
Url
Comment *  
 
Archives
Post Categories
other blogs
News