Test-Driven Development
Figure 8: A possible downside to Test Driven Development
Test-Driven Development, as its name implies, is derived from a programmer writing tests first, and then writing code. As the tests are written first, they fail until proper code is applied to them. Once the appropriate code is written, the test passes, and the next test is written. If the code as written does not pass the test, then it is adjusted until the test is passed (Grenning, 2007). An example of this process is shown in Figure 9, below.
Figure 9:
Much like the other agile processes that I have mentioned, with Test-Driven Development (TDD), jobs are broken up into small subsets that can be implemented in a short period of time. Code is developed through rapid iterations of minute-by-minute cycles and per-task cycles. The minute-by minute cycles consist of the following:
- Writing a small number of new and failing automated unit test case(s) for the task at hand
- Implementing code which should allow the new unit tests cases to pass
- Re-running the new unit test cases to ensure they now pass with the new code (Nagappan, Maximilien, Bhat, Williams, 2008).
The per-task cycles are as follows:
- Integrate code and tests for new code into existing code base
- Re-running all the test cases in the code base to ensure the new code does not break any previously running test cases
- Refactoring the implementation or test code (as necessary)
- Re-running all tests in the code base to ensure that the refactored code does not break any previously passing test cases (Nagappan, et al, 2008).
Some of the possible benefits of TDD include:
- Better design
- While it may appear that TDD removes the focus from design by implementing testing immediately rather than wading through a long design process, the process does have a strong focus on design (Janzen, 2006).
- Efficiency- test-then-code cycles give continuous feedback to the developers
- Test Assets- automated unit test cases are useful for regression testing
- Reducing Defect Injection- maintenance fixes and "small" code changes may be nearly 40 times more error prone than new development (Nagappan, et al, 2008).