什么场景不适合TDD？

在敏捷软件交付领域，大多数软件系统的业务需求在一开始是相对确定的，这种场景下TDD能够帮助开发人员在对需求细节理解无误的前提下，去做业务功能代码的编写。但TDD也有它不适应的场景，这里我列举了三种：

1. 对于那些业务需求存在很大不确定的系统，比如创业项目，可能存在一天好多次用户测试，然后根据反馈快速变更需求，这种情况自动化测试反而成为了一种需要付出较高成本去维护的脚（憋）手（足）架。
2. 如果你只是想快速Spike一个新的实现方案的时候，而这个Spike结果很可能不会被系统采用，也不建议采用TDD的方式。
3. 单纯从商业目标来看，如果一个非常紧急的系统，在开发完成后不会存在后续维护的的一锤子买卖的系统，这样的系统大可快速用野蛮的方式实现功能，但这是极端的例子，不过也是业界存在的现象。

更多场景，欢迎你在文末留言补充~