Test-driven development
|
|
Test-driven development (TDD) is a programming technique heavily emphasized in Extreme Programming. Essentially the technique involves writing your tests first then implementing the code to make them pass. The goal of TDD is to achieve rapid feedback and implements the "illustrate the main line" approach to constructing a program.
| Contents |
Requirements
In order for TDD to work in practice, the system must be flexible enough to allow for automated testing of code. The system must also have testcases in place before TDD can be used. These tests must also be simple enough to return a simple true or false evaluation of correctness. These properties allow for rapid feedback of correctness and design.
Test-Driven Development Cycle
1. Write the test
It first begins with writing a test. In order to write a test, the specification and requirements must be clearly understood.
2. Write the code
The next step is to make the test pass by writing the code. This step forces the programmer to take the perspective of a client by seeing the code through its interfaces. This is the design driven part of TDD.
3. Run the automated tests
The next step is to run the automated testcases and observe if they pass or fail. If they pass, the programmer can be guaranteed that the code meets the testcases written. If there are failures, the code did not meet the testcases.
4. Refactor
The final step is the refactoring step and any code clean-up necessary will occur here. The testcases are then re-run and observed.
5. Repeat
The cycle will then repeat itself and start with either adding additional functionality or fixing any errors.
Differing styles
There are various ways one can go about using TDD and the most common one is based on KISS (Keep it simple stupid) or YAGNI (You aren't going to need it). This style focuses on writing code anyway necessary in order to pass the tests. Design and property principles are cast aside in the name of simplicity and speed. Therefore, any rule can be violated as long as the tests will pass. This can be unsettling for many at first but it will allow the programmer to focus only on what is important. However, the programmer must pay a bigger fee in the refactoring step of the cycle since the code must be cleaned up to a reasonable level at this point before the cycle can restart.
Another variation of TDD requires the programmer to first fail the testcases. The idea is to ensure that the testcase really works and can catch an error. Once this is shown, the normal cycle will commence. This is one of the more popular variations and has been coined the "TDD Mantra", known as red/green/refactor where red means fail and green is pass.
Benefits
Despite the initial requirements, TDD can provide great value to building software better and faster. It offers more than just simple validation of correctness, but can also drive the design of a program. By focusing on the testcases first, one must imagine how the functionality will be used by clients (in this case, the testcases). Therefore, the programmer is only concerned with the interface and not the implementation. This benefit is similar to Design by Contract but approaches it through testcases rather than mathematical assertions.
The power of TDD offers is the ability to take small steps when required. It allows a programmer to focus on the task at hand and often the first goal is to make the test pass. Exceptional cases and error handling are not considered initially. These extraneous circumstances are implemented after the main functionality has been achieved.
Limitations
TDD cannot work in an environment where automated testing is not feasible. It is currently immature and faces a variety of problems.
- GUI
- Distributed Objects
- Database Schema
- Compilers and Interpreters from BNF to production quality implementation
It is also important to note that Test-driven Development only proves correctness of design and functionality according to the testcases written. An incorrect testcase that does not meet the specifications will produce incorrect code. Therefore, the emphasis on correctness and design has shifted to writing testcases since they are the drivers. As a result, Test-driven Development is only as good as the tests are.
External links
- Test-driven Development using NUnit (http://www.parlezuml.com/tutorials/tdd_nunit/index_files/frame.htm) tutorial by Jason_Gorman (dead link)
- An essay about TDD (http://www.agiledata.org/essays/tdd.html)
- testdriven.com (http://www.testdriven.com) on-line TDD community
- c2.com (http://c2.com/cgi/wiki?TestDrivenDevelopment) TDD from WikiWikiWeb (This is the Wiki princips)