Integration Watch: When 100% code coverage is not enough



Email    print   
February 15, 2009 —  (Page 1 of 2)
In my previous discussions of code coverage, I explained the reasons why 100% code coverage from tests is not a desirable goal. To recap, there is a lot of code that does not need to be tested, and writing code specifically to test it is simply a waste of time. For example, testing setters and getters is a recognized waste of time. Surely you have better things to do with your time.

Another common form of conceptually incorrect and equally wasteful testing is testing in a way that violates encapsulation, or more specifically, object integrity. Suppose that you have a linked list for holding tokens, and suppose that rather than wrapping the list in its own class, as you should, you just use the bare data structure as it’s provided by the library. Then, in your testing, you write a test that adds an item to the list and immediately retrieves it. Then it tests the two versions for equality.

What are you doing? You’re actually testing the data structure provided by the system library. You are not testing your code, but rather a pair of methods encapsulated inside a data structure in a different library. That is never right.

The desirability of 100% code coverage comes from an admirable but misdirected sense that unit testing the entire codebase improves the code’s reliability. This, however, is not the case. Simply because unit tests bring value in one setting does not mean that an excess of tests is a valuable thing.

However, for people inclined in this direction, there is a testing need that’s rarely discussed and rarely done, but which should gratify the desire to write tests: writing more than 100% coverage tests for certain methods.

Greater than 100% is an easily achievable goal. For example, attaining 100% branch coverage often means that a given line needs to be tested multiple ways, resulting in more than 100% line coverage for that line. One hundred percent branch coverage is a desirable goal. You definitely want to make sure that every path your logic can take has been tested. If you aim for 100% branch coverage, you’ll get very high line coverage and you’ll probably be close to the maximum of the test coverage you need.



Related Search Term(s): testing, Agitar

Pages 1 2 


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

Add comment


Name*
Email*  
Country     


  • Comment
Loading




close
NEXT ARTICLE
McCabe Software acquires Agitar's assets
Two months after Agitar Software ceased operations, McCabe Software swooped in and purchased its assets. McCabe says that it will continue customer and product support for Agitar's unit test tools 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