Test Driven Development (TDD)

Test Driven Development or TDD was claimed as re-discovered by Kent Beck as a form of test first programming and was introduced as an Extreme Programming (XP) practice that promotes the definition of expected behaviour in the form of unit tests prior to writing the code to satisfy them.

Test Driven Development Cycle

1. The cycle of TDD starts with writing a unit test that encapsulates the expected behaviour, sunny day and rainy day, to be satisfied by the intended code construct.
2. The next step is to run the suite of tests and determine which ones fail
3. If a test fails then write some code to resolve the test failure. N.B. If a rainy day test receives an expected exception, then this is a pass, in that, this is expected behaviour. # If it received a different exception or no exception at all, then this would be deviating away from the expected behaviour stated in the unit test, and hence, would be a failed test.
4. Next run the tests again to ensure that the test suite passes
5. Refactor any code that needs refactoring. N.B. If code is duplicated in more than one area then this may suggest that the code should be refactored. The eradication of technical debt and evolution towards an elegant design may also influence refactoring efforts. Unit tests can also be refactored for improved maintainability.
6. Goto the first step. N.B. Many small TDD cycles tend to work best especially when incorporating refactoring efforts rather than writing a bulk of tests, then writing a bulk of code and then having to fix a bulk of failed tests.

Benefits

• Refactoring and enhancing code with full suites of unit tests can be done quickly as running the unit tests provides immediate feedback as to whether there are any issues
• Other forms of testing such as functional testing and integration testing benefit from code that has been hardened with unit tests
• Development efforts tend to be more focussed to satisfy the expected behaviour in tests rather than over developing code
• If refatoring is incorporated well during the TDD cycles the code design grows in an elegant form that meets the expected behaviour rather than introducing assumptions, which may later be realised as constraints.
• A suite of passed tests provides a very good level of confidence in the team that their code works

Challenges

• Time taken to write tests can be exhaustive when compared to new code development time and may be very tempting to skip tests and just write code.
• New testing skills may need to be introduced to developers, as they are now tasked with providing enough test coverage of their code. Boundary value analysis for example, may be a new skill to be acquired by the developers to ensure that they have sufficient test coverage.
• The number of rainy day unit tests when compared to the number of sunny tests has been quoted as being as much as 10 rainy day to 1 sunny day, which may be a new discipline for developers.
• For extensive suites of unit tests, these may be overwhelming to maintain and keep current. Hence, refactoring tests may be just as important as refactoring code.

See Also

• Extreme Programming (XP)
• Behaviour Driven Development (BDD)
• Coding Dojo

References

1. Test Driven Development: By Example, Kent Beck, 2001
2. Extreme Programming Explained, Kent Beck and Cynthia Andres, 2004