Integration Watch: Continuous testing cometh



Email    print   
April 15, 2009 —  (Page 1 of 3)
A core practice of the agile movement is to release often. The goal of many small releases is to provide developers with feedback early and often on what they’re doing. It also allows users to make changes along the way that enable the project to completely fill its requirements and, especially, user and customer expectations.

As the practice of frequent releases proved to be a capable means of improving products by getting frequent input, agile practitioners realized it had a similar effect on developers within the development team. That is to say, if developers completed their coding cycle quickly and began the non-coding activities promptly, they could get near-immediate feedback on the changes they just made.

When thought about in this context, unit testing is a formidable tool for providing just such feedback. For example: You code, run tests, figure out what you broke, and decide how to respond to the tests’ feedback. You might suddenly discover that if you continue down the path you were innocently traveling, you will unhinge a key module that would take far too long to fix. You discreetly back up (you can tell how far to back up by the test feedback), and you devise a different approach that skirts the problem the unit tests have just flagged. This scenario makes good use of tests. And other similar examples all suggest that the sooner you run tests after you code, the earlier you can detect problems and make the necessary adjustments.

The recognition that the earlier you test your code, the easier it is to fix, spread out into new pastures a few years ago—namely, in builds. As all developers know, it’s not enough that code passes tests, it must also not break the build. To provide quick feedback on build-breaking check-ins, the practice of continuous integration emerged a few years ago. As I have discussed in previous columns, continuous integration software monitors a source-code repository and starts up a new build of the project every time code is checked in. This enables developers to know within a few hours whether they have broken the build and how.



Related Search Term(s): testing

Pages 1 2 3 


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

Bloomberg opens its API
Bloomberg's APIs could lead to a future standard for accessing market data.
02/01/2012 04:41 PM EST

The case for piracy
In the aftermath of SOPA and PIPA, some copyright holders have begun to embrace piracy as inevitable...and even beneficial.
01/30/2012 02:39 PM EST

Tablet sales boom, but applications lag
The installed base of tablet computers and e-book readers is growing rapidly, but no killer app has yet emerged -- hint, hint.
01/28/2012 05:48 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