In 1996, the European Space Agency watched in horror as the maiden flight of the Ariane 5 rocket automatically self-destructed 39 seconds into its flight. In 2001, NASA (in conjunction with the European Space Agency) was forced to admit that their $125 million Mars Climate Orbiter had instead become Mars Surface Debris. The link (other than the ESCA) is that both of these catastrophes were caused by software failures, and both were projects developed by some of the most rigorous programming method practitioners known to the industry.
Most software development projects follow a standard pattern for testing: Programmers develop code, which is checked into a common repository. At regularly scheduled intervals, and during major releases, the Quality Assurance department builds the application and tests it (sometimes manually, sometimes using automated scripts).
Let’s compare software development to another kind of authorship: writing a novel. An author, upon finishing a draft of a novel, will send it to the editor for review. The editor (and probably a team of reviewers) read the novel to make sure it makes sense, has no major flaws, and is fun to read. This is the acceptance testing phase for the novel; it takes the reviewers a long time to read the draft, and they are focused on large issues of plot and structure.
It is possible that during the writing of the novel, the author has been shipping individual chapters to the editor for review. In this case, there is a shorter interval between the writing and the reviewing. It takes less time to read a single chapter than a whole novel, and the issues reported are much more specific, although still focused on issues of structure and plot. This is a kind of module testing.
Enter the spellchecker.
Writing a novel using a modern word processor, authors get immediate feedback on their spelling and grammar. Hundreds of minor mistakes are corrected the moment they are made. They won’t catch everything, but they don’t have to. The resulting manuscript is so much cleaner by the time it gets to the reviewers that they can focus their energies on the things that can’t be caught by a spellchecker. The resulting product is that much stronger.
The spellchecker is for the author a kind of unit testing. Unit testing is the act of writing test code to verify your own production code. Unit testing is done by the programmer, and the immediate benefit is to the programmer. Each individual unit of functionality (method) is tested, in isolation where possible, to make sure that the individual building blocks of your application are solid. By limiting the amount of functionality being tested, and controlling the environment in which it is tested, you can verify the code itself while minimizing the unpredictable effects of context.
Perhaps more importantly, unit testing offers the shortest feedback cycle between writing code and finding out if you wrote it incorrectly. Bugs are always easiest to fix when the code is fresh. Waiting until end-of-cycle testing gives you an opportunity to forget why and how you wrote a specific unit of functionality.
Tools:
NUnit, an open source unit testing framework for .NET, and provides a group of test running applications and tools for reporting the results. Since most unit testing is done using a standardized framework like NUnit, the tests can be run automatically by an integration tool (such as NAnt or make) and results sent to the team members. NUnit, and the Unit allow you to write test code in the same language as your production code, and they each provide a collection of test runners, applications which automate the process of running the tests and reporting on the results. VSNUnit is an open-source add-in for Visual Studio .NET developed by the author that provides instant, automated testing and feedback