Test Driven Development
Test-driven development (TDD) is a software development techinique that uses short development iterations based on pre-written test cases that define desired improvements or new functions. Each iteration produces code necessary to pass that iteration’s tests. Finally, the programmer or team refactors the code to accommodate changes. A key TDD concept is that preparing tests before coding facilitates rapid feedback changes.
Test-driven development is a software design method and not merely a method of testing.
Test-Driven Development is related to the test-first programming concepts of Extreme Programming. Programmers also apply the concept to improving and debugging legacy code developed with older techniques.
Now the question is how to go about it. So following is the cycle of TDD -
Add tests for any new functionality or a scenario. These new tests are suppose to fail as there is no relevant code for it. To write a perfect test case a developer should clearly understand the requirements. And this can be achieved from the use cases that covers the requirements and exceptions if any.
If there is change in the requirement this could also result in changes in some existing tests. These modified tests are implied to fail as there is no code changes yet.
Run all tests and see if all the new ones and the newly modified ones fail. They should fail as discussed above. This ensures that the test harness is working fine and the new tests are not passing even though there are no code written corresponding to them.
This step actually tests the test itself in a negative way to ensure that the test fails in situations where it should not pass. This increases the worth of the tests.
Add require code inorder to pass the newly added tests. This could also result in writting codes that would pass all tests in an inelegant way. But no worries, the code written here may not be perfect, the subsequent steps will ensure that the code written is improved to achieve the actual objective.
The primary objective here is to pass the tests. 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.
Run the automated tests once the newly created tests are passing. The programmer can be sure that the code written map to all testing requirements and the functionalities. This would be the correct point to move ahead with the final steps.
Refactor code for possible code clean up. Code is to be cleaned up to improve the functionality and to make sure that there is no duplication. After each refactoring the test suite should be executed again. This will ensure that the refactored code does not impact the tests.
Repeat untill goal is reached.
Conclusion: Write the tests first and then fail them. Write the appropriate code to pass the tests. Refactor and improve code and retest.
Advantages
- There is better code quality.
- Helps to build better and faster softwares.
- There is hardly a need to start the debugger.
- Increases productivity of the programmer.
- Decreases the changes of bugs in the initial code.
- Programmers can focus better on the small task of making the test pass.
- The tests can be used to create exceptions and thus error handling improves.




Leave a Reply