Blind Spots and Frequent Testing



Email    print   
January 15, 2005 —  (Page 1 of 3)
The requirement that submissions to open-source projects be accompanied by unit tests reflects the trend among developers to perform frequent unit testing (FUT). I coin this acronym because I need to capture this comparatively new activity. It’s one step down from Extreme Programming’s Test-Driven Development (TDD) in that the code is written first (then immediately tested). My perception is that many exponents of TDD eventually drift into FUT. The tendency to write code first is both natural and expedient.

The trouble with FUT is that the tests and code are developed nearly in tandem, and so they fit each other well. Tests frequently focus on the main use case and then add the occasional edge value to make sure maximum, minimum and special values do not break the code. Not surprisingly, the test cases reflect the code already in the routine. The result is that the tests simply reinforce the perception that the code is functionally correct, without in fact really exercising potential weaknesses. I’ll come back to this in a moment.

A second problem, which needs attention if FUT ever is to do more than baseline validation, is to design frequent larger-than-unit tests. (I’ll avoid a new acronym here.) Unit tests are very much a bottom-up experience, designed and performed at a low level. They inspire a false confidence that the functionally correct units work together properly. This higher level of correctness, fortunately, is covered by standard testing tools that can drive cross-unit interfaces, simulate transactions and test systems under load. The trouble is, these tests are not run as frequently as unit tests because they take longer to develop and run—meaning that feedback to the developer is never immediate and often distant from the coding work by days, weeks, even months.

These larger tests are typically written by QA and test engineers rather than the developers themselves, and as a result they are less prone to testing what is already known to work. Testers can see in the code things that developers miss.




Pages 1 2 3 


Share this link: http://sdt.bz/28368
 
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