tdd - 测试驱动开发 "Barriers to Entry"?

Question

我正在研究测试驱动开发，其中一个讨论点是与 TDD 相关的“进入壁垒”。有没有人在这方面有任何经验，在您参与的任何项目中，由于进入阈值太高而决定不使用 TDD？

据我所知，进入的唯一障碍是个人开发人员的知识(以及经验)，大多数人并不完全习惯这个过程，而且有点陌生。鉴于大多数市场领先的工具都是开源的、免费提供的、有据可查的并且得到很好的支持，从财务角度来看，它似乎非常有吸引力。

思想/感情受到赞赏。

谢谢，

编辑 - 有没有人知道提倡 TDD 的人的任何高调引述？很想看看它在链条上有多高。干杯。

Answer 1

一些障碍包括:

不适合单元测试的现有代码库。

难以进行有意义的单元测试的问题域，例如 GUI 工作或与第三方系统的集成。

对单元问题的集成问题的看法(换句话说，如果它不能端到端地工作，那么它什么都不做，那么测试单元的意义何在)。

想要提前设计并拥有清晰的系统设计而不是试驾设计的心态

一种政治文化，其中设计由与开发不同的人/团队完成，并且该设计不适合单元测试。

无法克服 TDD 与一致性测试无关的事实(诸如“编写测试的人不应该是编写测试的人，他们对自己太宽容”之类的论点)。

到目前为止，他们的编码方式并非如此，因此转变更加困难。

有时某个测试可能很难设置，因此该方法将被放弃，因为它“感觉”较慢。

不适合或根本不适合演进设计的设计要求(认为核电站控制软件或其他系统的实际生活取决于它们的正常运行)。

如果每个人都没有在 checkin 代码之前运行测试，那么由于错误的原因，测试开始经常中断(即代码的预期行为改变了，但测试没有跟上，所以测试是错误的，而不是代码)，因此它们可以被视为拖累。