为什么开发人员不喜欢 TDD?


测试驱动开发(TDD)是一种软件开发过程,依赖于短期开发循环的重复:

  • 首先开发人员编写一个自动化测试用例来定义所需的改进或新功能,
  • 然后编写代码来通过该测试,
  • 最后重构新代码以符合可接受的标准。

然而,很少有开发人员完全遵循这种方法(我们在OneUptime肯定不会)。

以下是原因:
API的承诺:TDD要求在完全了解所需功能之前就要对API做出承诺。这可能是一个重大缺点,特别是在开发的早期阶段,当您仍在探索不同的可能性时。

迭代过程:在开发的早期阶段,迭代是关键。您不仅需要编写代码,还需要了解问题空间、潜在解决方案以及它们之间的权衡。

这个学习过程至关重要,而TDD有时可能会阻碍这个过程。

稍后添加测试:一旦您满意API,测试就会起作用。在确定API之后编写测试允许您专注于确保代码按预期工作,而不是花时间更新测试以反映API的更改。


要点:

  • TDD要求在完全理解其功能之前,开发人员就要承诺一个API,这可能在开发早期阶段限制了灵活性。
  • 在开发的早期阶段,迭代是关键,而TDD有时可能会阻碍这个学习过程。
  • 在满意API后再添加测试,可以更好地利用测试,而不会在探索阶段拖慢开发速度。

TDD在软件开发生命周期中有其位置,但并不总是适用于每种情况。

banq注:TDD属于软件教条主义的一部分,测试需要,但是不一定以测试为驱动开发,测试的本质是设置上下文环境,实则是上下文 驱动开发,上下文 驱动软件设计, 上下文 驱动代码编写。这些才是软件开发本质,没有人指出