测试驱动开发（TDD）是一种软件开发过程，依赖于短期开发循环的重复：
- 首先开发人员编写一个自动化测试用例来定义所需的改进或新功能，
- 然后编写代码来通过该测试，
- 最后重构新代码以符合可接受的标准。
然而，很少有开发人员完全遵循这种方法（我们在OneUptime肯定不会）。
以下是原因：
对API的承诺：TDD要求在完全了解所需功能之前就要对API做出承诺。这可能是一个重大缺点，特别是在开发的早期阶段，当您仍在探索不同的可能性时。
迭代过程：在开发的早期阶段，迭代是关键。您不仅需要编写代码，还需要了解问题空间、潜在解决方案以及它们之间的权衡。
这个学习过程至关重要，而TDD有时可能会阻碍这个过程。
稍后添加测试：一旦您满意API，测试就会起作用。在确定API之后编写测试允许您专注于确保代码按预期工作，而不是花时间更新测试以反映API的更改。
要点：
- TDD要求在完全理解其功能之前，开发人员就要承诺一个API，这可能在开发早期阶段限制了灵活性。
- 在开发的早期阶段，迭代是关键，而TDD有时可能会阻碍这个学习过程。
- 在满意API后再添加测试，可以更好地利用测试，而不会在探索阶段拖慢开发速度。
TDD在软件开发生命周期中有其位置，但并不总是适用于每种情况。
banq注：TDD属于软件教条主义的一部分，测试需要，但是不一定以测试为驱动开发，测试的本质是设置上下文环境，实则是上下文 驱动开发，上下文 驱动软件设计， 上下文 驱动代码编写。这些才是软件开发本质，没有人指出