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

测试驱动开发（TDD）是一种软件开发过程，依赖于短期开发循环的重复：

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

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

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

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

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

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

要点：

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

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

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

https://www.jdon.com/71209.html