In this section we pose several questions about the TDD pill that may temper TDD’s effectiveness in different contexts.
There is no recommended best context for the use of TDD. We do not know whether it is applicable to all domains, to all kinds of tasks within a domain, or to projects of all sizes and complexities. For example, the trials do not make it clear whether TDD is an applicable practice for developing embedded systems or for developing highly decentralized systems where incremental testing may not be feasible. Furthermore, it is often considered a challenge to use TDD for legacy systems that may require considerable refactoring of existing code to become testable.
One basic fact on which almost everyone agrees is that TDD is difficult to learn. It involves a steep learning curve that requires skill, maturity, and time, particularly when developers are entrenched in the code-then-test paradigm. Better tool support for test-case generation and early exposure in the classroom to a test-then-code mentality may encourage TDD adoption.
Personal communications with TDD developers suggest that it is an addictive practice. It changes the way people think and their approach to coding in a way that is difficult to roll back. Therefore, leaving TDD practices may be as difficult as adopting them.
No studies focus specifically on whether TDD performs ...