在敏捷软件交付领域，大多数软件系统的业务需求在一开始是相对确定的，这种场景下TDD能够帮助设计一个简单可用的系统。

对于那些业务需求存在很大不确定的系统，比如创业项目，可能存在一天好多次用户测试，然后根据反馈快速变更需求，这种情况自动化测试反而成为了一种需要付出较高成本去维护的事情。

另外，当你要快速Spike一个新的实现方案的时候，而这个Spike结果很可能不会被系统采用，也不适合TDD。

单纯从商业目标来看，如果一个非常紧急的系统，在开发完成后不会存在后续维护的的一锤子买卖的系统，这样的系统大可快速用野蛮的方式实现功能，但这是极端的例子，不过也是业界存在的现象。