Unit testing: Difference between revisions
imported>Ed Poor |
imported>Ed Poor (→Automated unit testing: Compare expected to actual) |
||
| Line 9: | Line 9: | ||
==Automated unit testing== | ==Automated unit testing== | ||
The second sort of unit testing seems paradoxical. The programmer writes automated tests, i.e., a program which verifies the program. Some advocates of automated unit testing even recommend writing a test that won't even compile, because there is literally nothing to test yet. In that case, the first task is to write stub routines so that the test compiles (but fails). | 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 automated unit testing even recommend writing a test that won't even compile, because there is literally nothing to test yet. 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]]). | 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]]). | ||
Revision as of 08:58, 10 May 2007
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:
- Write it first, then check for bugs
- 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 automated unit testing even recommend writing a test that won't even compile, because there is literally nothing to test yet. 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).
See also
Bibliography
Refactoring, Martin Fowler
Extreme Programming, Kent Beck