测试驱动的开发"进入障碍"？

Question

我正在研究测试驱动开发,其中一个讨论点是与TDD相关的"入门障碍".有没有人在这个领域有任何经验,你曾经做过的任何决定不使用TDD的项目,因为进入门槛太高了？

从我可以看出,进入的唯一障碍是个体开发者的知识(以及经验),大多数人并不完全习惯于这个过程而且有点陌生.在财务方面,由于大多数市场领先的工具都是开源的,免费提供,文档齐全且得到良好支持,因此它似乎非常具有吸引力.

思想/感受赞赏.

谢谢,

编辑 - 有谁知道任何高调引用人们提倡TDD？很想知道链条有多高.干杯.

Answer 1

一些障碍包括:

1. 现有的代码库,不适合单元测试.
2. 一个难以有意义地进行单元测试的问题域,例如GUI工作或与第三方系统的集成.
3. 对单元问题的集成问题的看法(换句话说,如果它不能端到端地工作它不会做任何事情,那么测试单元的重点是什么).
4. 想要提前设计并拥有清晰的系统设计而不是通过测试推动设计的思维方式
5. 一种政治文化,其设计由与开发不同的人/团体完成,并且该设计不是单元测试友好的.
6. 无法克服TDD不是为了测试一致性的事实(诸如"编写测试的人不应该是编码测试的人,他们对自己过于宽容"这样的变体).
7. 直到现在他们才开始编码,所以这种转变更难.
8. 有时某个测试很难设置,因此该方法会因为"感觉"变慢而被放弃.
9. 设计要求不能很好地适应不断发展的设计或根本不考虑(认为核电厂控制软件或其他系统的实际寿命取决于它们的正常运行).
10. 如果每个人在检入代码之前都没有运行测试,那么测试会因为错误的原因而开始经常中断(这是代码的预期行为发生了变化,但是测试没有跟上,所以测试是错误的,而不是代码)所以他们可以被视为拖累.

Answer 2

就进入壁垒而言,实际上,因为您明确编写了在代码被认为完成之前必须通过的测试,所以在获取功能代码所涉及的开发周期中的提前期更长.现在,当使用TDD时,您可以有效地保证代码的某种程度的质量(无论您选择哪种质量级别进行测试),因此通常对提前期的延迟进行补偿,但严格来说,使用TDD获取功能代码需要更长的准备时间.

实际上,如果你有编写无错误代码的程序员,TDD将会拖累你的开发周期.当然,TDD的价值在于没有任何编码人员可以随时编写无错误的代码,因此修复错误的成本必须在某个地方考虑​​因素; 在TDD中,测试基础设施的成本是前置的.

请注意,这对TDD没有任何负面影响; 我只是说,前装可能被认为是"进入障碍".就个人而言,作为一名程序员,我会说投资回报是值得的,我认为大多数经验丰富的开发经理也会如此.