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 you write the code required to pass the test. You then refactor that code to eliminate any duplication and overlap, and then you repeat this process 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?).
Here's the basic TDD flow:
- The developer accepts a unit of work and immediately writes a set of tests that will prove that the unit of work actually functions correctly. In some organizations, the test cases that are 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 few rare organizations that create both levels, and this might be a best practice. Think about using the Three Amigos Technique to develop robust test cases.
- Now, you 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 needed to solve the problem - and write just enough code to solve the problem.
- Run the test suite again. This time, the test should pass 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 to remove any possible duplication.
Now, you repeat these steps 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 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.
Make sense? If not, feel free to leave a question for me in the comments (or on Twitter, I'm @TCagley)!
Vice President of Consulting
Agile Practice Manager