What is TDD?
Test-Driven Development (TDD) is a software development technique consisting of short iterations where new test cases covering the desired improvement or new functionality are written first, then the production code necessary to pass the tests is implemented, and finally the software is refactored to accommodate changes.
Practitioners emphasize that test-driven development is a method of designing software, not merely a method of testing.
Test-Driven Development Cycle
1.
Add a test
In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. In order to write a test, the developer must understand the specification and the requirements of the feature clearly. This may be accomplished through use cases and user stories to cover the requirements and exception conditions. This could also imply an invariant, or modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.
2.
Run all tests and see if the new one fails
This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code.
3.
Write some code
The next step is to write some code that will cause the test to pass. The new code written at this stage will not be perfect and may, for example, pass the test in an inelegant way. That is acceptable because later steps will improve and hone it.
It is important that the code written is only designed to pass the test; no further (and therefore untested) functionality should be predicted and ‘allowed for’ at any stage.
4.
Run the automated tests and see them succeed
If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.
5.
Refactor code
Now the code can be cleaned up as necessary. By re-running the test cases, the developer can be confident that refactoring is not damaging any existing functionality.
Repeat
Starting with another new test, the cycle is then repeated to push forward the functionality. The size of the steps can be as small as the developer likes, or get larger if s/he feels more confident.
TDD Benefits
*
Improve software quality by providing 100% test coverage.
*
Improve code design by forcing developer to think outside of the code as a critics.
*
Increase developer productivity.
”A 2005 study found that programmers that wrote more tests tended to be more productive” (see the research at http://en.wikipedia.org/wiki/Test-driven_development#Benefits)
*
Minimize/Remove debugging/troubleshooting time.
“Programmers using pure TDD on new (”greenfield”) projects report they only rarely feel the need to invoke a debugger” (see http://en.wikipedia.org/wiki/Test-driven_development#Benefits)
*
Code Implementation time is shorter.
“While it is true that more code is required with TDD than without TDD because of the unit test code, total code implementation time is typically shorter.” (see http://en.wikipedia.org/wiki/Test-driven_development#Benefits)
*
Makes Refactoring easy by removing bug fears.
TDD Disadvantage
*
The tests themselves become part of the maintenance overhead of a project.
*
Developer aptitude towards writing test case.
*
Management support is essential. (http://people.apache.org/~stevel/slides/testing.pdf)
javablogspot 