Test Driven Development (TDD) is an approach to development in which you write a test that proves the piece of work you are working on, and then write the code required to pass the test. You then refactor that code to eliminate duplication and any overlap, then repeat until all of the work is completed. Philosophically, Agile practitioners see TDD as a tool either to improve requirements and design (specification) or to improve the quality of the code. This is similar to the distinction between verification (are you doing the right thing) and validation (are you doing the thing right).
The Basic TDD Flow
- The developer accepts a unit of work and writes a set of tests that will prove that the unit of work actually functions correctly. In some organizations the test cases written are unit and functional tests (focused on code quality), while in others the test cases are acceptance test cases (focused on specifications/requirements). There are a rare few organizations that create both levels, and this might be a best practice. Think about using the Three Amigos Technique to develop robust test cases.
- Run the tests. The tests should fail because the code to solve the business problem embedded in the unit of work has not been written. If the tests pass, rewrite them (I would check to make sure that no one else has solved the problem and failed to tell you – this would be a communication and configuration problem).
- Write the code need to solve the problem. Write just enough code to solve the problem.
- Run the test suite again. The test should pass at the point based on the solution created in step three. If one or more tests don’t pass, return to step three and correct the code. Repeat steps three and four until all tests pass.
- Refactor the code and design to make the design as simple as possible and remove any possible duplication.
**Repeat the loop until all of the work is complete for the iteration.
Test Driven Development is an extension of test-first development (TFD) in which developers will not write a single line of code until they have created the test cases needed to prove that unit of work solves the business problem and is technically correct. TDD extends TFD by adding the final step to refactor the design and code to avoid duplication and to promote simplicity. The concept of TDD turns classic software development concepts on its head. Classic approaches begin with the assumption of a known design that is at the very least sufficient, and that the developers will create code first and test afterwards. TDD assumes that the design will be refactored based on what is discovered during development and that development will not begin until the tests have been developed.