Recently, I had the chance to sit down with Scott Bain, author of Emergent Design and an expert in Test-Driven Development. He wanted to talk about what he has seen as impediments to implementing Test-Driven Development: impediments that arise before an organization decides to adopt TDD and impediments that arise after adopting TDD. He bases this on his conversations with clients who are in the midst of implementing TDD, on his coaching experience, and on own personal journey with TDD has he has incorporated the concepts into Net Objectives training in Design Patterns, TDD, and Analysis.
Before organizations decide to adopt test-driven development, they usually have to address one or more of these challenges:
The impediments do not stop after TDD has been adopted. What we see is that after Iteration 3, the TDD effort begins to collapse. It takes too long, the tests are difficult to change, or it is hard to keep up with multiple tests
The answers to both of these impediments lies in gaining a new, essential insight: in TDD, the entities we write not not actually tests. They are specifications. What we are doing is replacing traditional specs with automated specs.
The process of writing the specification is an analysis task, one that leaves behind a suite of tests as a side-effect artifact; thus, it is not double work.
TDD does not replace Quality Assurance. They will not be sufficient for all testing.
TDD is another fundamental skill that developers, especially Agile developers, must have. It is something that they can learn when they receive proper training.