Rails 大神、创始人 David Heinemeier Hansson 曾发文抨击TDD。
TDD is dead. Long live testing. (DHH)
此后, Kent Beck、Martin Fowler、David Hansson 三人就这个观点还举行了系列对话（辩论）
Is TDD Dead?
笔者作为一个多年在软件测试领域摸索的人，其实更多是跟同行们澄清 "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 本身就是先天难产