Rails 大神、创始人 David Heinemeier Hansson 曾发文抨击TDD。
TDD is dead. Long live testing. (DHH)
此后, Kent Beck、Martin Fowler、David Hansson 三人就这个观点还举行了系列对话（辩论）
笔者作为一个多年在软件测试领域摸索的人，其实更多是跟同行们澄清 "TDD并不是测试活动"，“TDD是开发活动”， TDD这里的“测试”和我们正常理解的软件测试并不是一个东西。
倒是很少认真思考过 TDD 本身的价值在哪？是不是真的有用。
这里就谈谈自己的理解：
1. TDD本身是一个开发实践
或者说是一种产品设计实践，准确说应该是对应软件的详细设计。
思路其实就是先根据需求，将需求拆分到足够细。在代码实现之前，传统的研发流程中会有详细设计，到伪代码这个层级。TDD其实起到的是类似的目的，只是方式上变成先思考这个需求拆分到方法级别后，方法对应的产出是什么，方法到达到什么目的。思考的结果就是先完成这里的Test，对应的其实是单元测试。
在有了各种路径和场景的Test之后，再编写代码让这些测试通过，这样其实就完成了功能的实现。
这样带来的好处是，因为测试已经包含了需要的逻辑，这样就便于产品的不断迭代、重构，只要测试能够通过，就不会担心因为修改导致功能的不可用。会为产品的不断优化提供保障。
理论上听起来不错，而且似乎也受到行业的广泛推崇。不TDD似乎就落伍了
2. TDD在现实中并不成功
作为多年的测试工程师视角，也参与过大量软件项目，其中不乏很多项目重点推行TDD的实践，并引入咨询师进行指导。但就我的个人观察，没有成功的。也没有一线的开发人员能真正地坚持TDD，大部分实践TDD的项目，最终也就不了了之。
结合题主给出的线索，这里的答案可能就是 “TDD已死”，或者就我个人的体会，TDD是一个理想化的产物，在实际实践中，放到复杂的产品需求和团队合作中，很难把理想落地并发挥它预期的作用。（题外话，敏捷项目实践也有点类似，理想化的产物）
3. 为什么TDD难以真正落地？
1）ROI不高。要达到TDD的目的，测试代码会是实现代码的数倍，在软件项目大部分都是进度、资源稀缺的情况下，按理想情况去投入TDD并不现实。
2） 更多是只从最小的方法层面去覆盖。即便足够高的单元测试覆盖，依然会有集成测试、系统测试的场景遗漏，集成测试、系统测试依然不可或缺。TDD本身对质量的保障作用不明显。（这也是为什么我说TDD更多是设计实践，不是测试实践；是开发活动，不是测试活动）
3）方法层面进行测试覆盖，必然牵涉到大量依赖Mock，而mock本身其实就潜在数据、场景和实际有偏差的风险。
4）开发工程师的思维模式其实更趋向追求确定性，而测试的思维模式是需要基于各种不确定性去发现测试路径。开发和测试这两种活动，先天上是比较对立的。一定要让一个角色去同时完成这两种活动，有点勉为其难。
所以我的看法：确实 TDD已死，或者说 TDD 本身就是先天难产
标签：实践,TDD,开发,测试,已死,其实 From： https://blog.csdn.net/danmyw/article/details/142888346