Characterization: Beyond Pure Unit Testing



Email    print   
March 15, 2007 —  (Page 1 of 2)
If asked to explain, practitioners of unit testing generally recommend the practice because it enables them to be sure their code does what they expect it to. It is a mechanism that gives some reasonable belief that the base being built is solid—that is, it works correctly given a variety of inputs and under varying conditions.

For me—a strong believer in unit testing—the practice has other advantages that are less discussed but certainly acknowledged by developers.

One is that I can reasonably extrapolate when I will be done with a project. The aspect that historically made guessing completion milestones so difficult was that the coding cycle generally opened onto an extensive debugging cycle whose extent and duration were unknown. This was so because developers preferred doing the minimum amount of testing necessary to move forward with feature creation. So, when the package was pushed to QA, simple tests with out-of-range values frequently revealed design flaws and weaknesses that required rewriting large sections of code. Unit testing removes this problem. If I write good unit tests, this kind of refactoring almost completely disappears. So, the estimation I am left with is guessing how long it will take to write the original code and the accompanying unit tests. In general terms, I can estimate this fairly well. And so unit testing gives me the key ability to map out work in a sensible way and proceed according to a known, reasonable schedule.

Another benefit of unit testing is my central theme. By writing lots of unit tests, I create hundreds, even thousands, of seismographs that are embedded in my code. If new code disturbs some functionality or undoes an invariant of my previous code, one of those seismographs will generate a fault message in the form of a failing unit test. This is invariably a valuable insight (and one, I might add, that is possible only if all unit tests are run regularly.)

The concept of using unit tests as seismographs that monitor existing code has been given new life recently in work by Michael Feathers that first appeared in his excellent book “Working Effectively with Legacy Code” (Addison-Wesley, 2004). In it, Feathers discusses “characterization tests.” These are unit tests written explicitly for the purpose of capturing the current functionality of code. The tests are not intended to prove the quality of code, but merely to record how it operates. (Remember the book’s theme is dealing with legacy code, which Feathers defines as existing code with no unit tests.) The benefit is that if you’re refactoring legacy code, you can tell if you’ve disrupted it when any of these characterization tests fail. When you think about




Pages 1 2 


Share this link: http://sdt.bz/30275
 
Most Read Latest News Blog Resources

Add comment


Name*
Email*  
Country     


  • Comment
Loading




close
NEXT ARTICLE
Not so fast when it comes to testing in the cloud
Developers face outsourcing, virtual lab management and mobile devices as obstacles Read More...
 
 
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 

Download Current Issue
FEBRUARY 2012 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?


 
blogs tab
Are you at risk for burnout?
Burnout is a severe problem and it can strike at any time. Here's how to tell if you are nearing the edge.
02/09/2012 02:16 PM EST

Agility, mom, and apple pie
If we're to evaluate the state-of-the-art in software development, we should start with the values espoused in the Agile Manifesto.
02/07/2012 11:57 AM EST

RIM woos developers with free tablet
How do you get more apps ported to the BlackBerry PlayBook? By giving every developer a free tablet, of course!
02/04/2012 01:57 PM EST

GitHire: Use Headhunters to Find Your Perfect Programmer
Are you a hiring manager tired of scouring the job boards? Check out this new service that will find 5 people interested in your jobs.
02/03/2012 12:17 PM EST

Facebook claims hacker cred
Facebook's SEC S-1 filing form includes a short essay on the Hacker Way by Mark Zuckerberg himself.
02/02/2012 08:26 AM EST

Ryan Dahl steps down
Ryan Dahl, creator of Node.js, steps back from his position as gatekeeper for the project.
02/01/2012 04:58 PM EST

 
Events calendar tab
2/13/2012 to 2/16/2012
Santa Clara
TechWeb

2/26/2012 to 2/29/2012
San Francisco
BZ Media

2/27/2012 to 3/2/2012
San Francisco
RSA

3/4/2012 to 3/7/2012
Las Vegas
IBM Tivoli

3/5/2012 to 3/9/2012
San Francisco
TechWeb