Over and over I find teams that use Test-Driven Development get serious results, including improved quality and faster delivery. However, not everything is light, kittens and puppies or everyone would be doing test-first development or one its variants (TDD, ATTD or BDD). The costs and organizational impacts can lead organizations into bad behaviors. Costs and behavioral impacts (cons) that we explored in earlier articles on TFD and TDD include:
- All test-first techniques require an investment in time and effort. The effort to embrace TDD, ATDD or BDD begins when teams learn the required philosophies and techniques. Learning anything new requires an investment.
- Early in a development project developers might be required to create stubs (components that emulate parts of a system that have not been developed) or testing harnesses (code that holds created components together before the whole system exists) which requires time and effort (often percieved to be a waste of time).
- Effective TDD requires automated testing. This is an inferred criticism of the effort, time and cost required for test automation. Test automation is important to making TDD efficient.
- TDD, ATDD or BDD doesn’t replace other forms of testing. Organizations that decide that test-first techniques should replace all types of testing are generally in for a rude awakening.
- TDD does not help teams to learn good testing. What does lead people to learn to test is the discussion of how to test and gaining experience supported by team members with testing knowledge and experience
Other potential behavioral changes that aren’t always anticipated include:
- TDD is a unit testing method. Tests cases should not have dependencies either between individual tests or requiring dependencies between system states. These types of tests require a level of coordination between stories that violate the concept of INVEST (remember I is for independent).
- TDD should not be used to test implementation details. TDD focuses on testing the coding-specific user stories. Attributes such as implementation, technical and non-technical details are typically better addressed by a definition of done condition or as system or integration test cases rather than as unit level tests cases of TDD.
- You can’t fake it until you make it. TDD requires a team and organization to understand Agile and to be committed to practicing Agile principles. While TDD can help a team “be” Agile, just trying to do TDD without understanding Agile principles or while trying not be Agile (and not get caught) can lead to poor testing. One symptom of this problem can be observed when defects crop up later (chronically) in the development cycle as other stories build on the original code which the TDD test cases should have caught.
Embracing TDD requires effort to learn and implement. If you can’t afford the time and effort, wait until you can. Embracing any of the test-first techniques will require that teams change their behavior if that is non-starter learning TDD is an academic exercise. If you are not willing to invest the time and effort in automation either hire a WHOLE lot of manual testers to pretend to be an automated solution or wait to implement TDD until you can bite the automation bullet.