Integration Watch: Continuous testing cometh
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
Share this link: http://sdt.bz/33398