Unit testing

Unit testing of computer software ensures that a component of a computer program works as intended. For example, a square root function should return a number which, when multiplied by itself, is sufficiently close to the original argument of the function.

The two most common ways of testing a component are:

1. Write it first, then check for bugs
2. Automated unit testing

Code and fix

The first sort of unit testing, derisively called "code and fix" by prominent author Steve McConnell, has several problems. It takes a lot of time and often does not find all errors. The cost of fixing software bugs rises exponentially during the software development cycle. If the problem is found in the design phase, it's relatively easy to fix. If it's found while coding is going on, but the software has not shipped (i.e., been published), it's harder to fix but still feasible. If the software ships with a defective routine, then at best a new release will have to be created and distributed. At worst, loss of equipment and human life can occur (see Ariadne software bug).

Automated unit testing

The second sort of unit testing seems paradoxical. The programmer writes a suite of automated tests, i.e., a program which verifies the program. The simplest sort of test exercises a routine by feeding it inputs and comparing outputs to expected values. For example, a square root routine should return a result of 5.000000 for an argument of 25.

Some advocates of test-first development even recommend writing a test that won't compile, if there is no existing code in place to test. In that case, the first task is to write stub routines so that the test compiles (but fails).

Once a test (or suite of tests) has been written, the programmer then writes just enough programming code to make the tests pass. At this point, he stops because there is nothing left to do. Once all tests pass, there is no "debug-test" cycle.

Advocates such as Kent Beck and Martin Fowler consider this a great advantage (see Refactoring).

Testing and refactoring

In test-first development, the credo is "Don't write code until you have a failing test" and "Do the simplest thing that could possibly work."

With a suite of automated unit tests in place, refactoring is transformed from a risky venture into a valuable and risk-free process. The structure of the computer program can be changed radically, with no chance of introducing software defects, because after each change the programmers run the automated tests again. As long as all the tests pass, there is no problem.

Usually refactoring is accomplished in a series of small steps as the program evolves towards the new design.

See also

• Software bugs

Bibliography

Fowler, Martin; John Brant, William Opdyke, Don Roberts (July 1999). Refactoring: Improving the Design of Existing Code. Addison Wesley. ISBN 0201485672. 

Beck, Kent; Cynthia Andres (November 2004). Extreme Programming Explained: Embrace Change, 2nd edition. Addison-Wesley Professional. ISBN 0321278658.