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 better or worse when used with other medications. In one trial, it is suggested that, when coupled with up-front design, TDD results in a 40% improvement in external quality [Williams et al. 2003]. Another trial compares solo and pair developers who practice TDD and incremental test-last development [Madeyski 2005]. That trial reports no difference in the external quality of software produced by solo or pair programmers using TDD. It is not known which practices go well or poorly with TDD. Although there may be practices that stimulate its desired effects, there also may be some that inhibit them. The examples just mentioned are probably case-specific, but they point out the need to investigate further TDD’s interaction with other medications.