阅读对这个问题的回答测试驱动开发的缺点？我的印象是，对于什么是TDD以及应该如何进行，存在很多误解。在这里解决这些问题可能会很有用。

解决方案

回答

我经常看到的误解是，TDD确保了良好的结果。

通常，测试是从有缺陷的需求中注销的，因此，开发人员生产的产品不能达到用户期望的效果。我认为，TDD的关键是与用户一起定义需求，同时帮助管理他们的期望。

回答

我认为这些问题颇具争议，因此容易引起误解：

• 以我的经验，最大的好处是可以花很多时间编写测试，从而生成更好的代码。因此，对于需要高质量的项目而言，这确实值得，但在其他一些以质量为中心的站点上，多余的时间将不值得。
• 人们似乎认为，仅必须测试这些功能的主要子集，但这实际上是错误的恕我直言。我们需要对所有内容进行测试，以使测试在重构后生效。
• TDD的最大缺点是不完整的测试会给人以错误的安全感：我见过网站瘫痪是因为人们认为单元测试足以触发部署。
• 无需使用模拟框架来进行TDD。它只是一种用于以更简单的方式测试某些案例的工具。最好的单元测试虽然在堆栈中被炒得很高，但在代码的各个层上应该是不可知的。在这种情况下，一次测试一层是没有意义的。

回答

我看到很多人误解了哪些测试实际上对TDD有用。人们编写大型验收测试而不是小型单元测试，然后花太多时间维护他们的测试，然后得出结论，TDD不起作用。我认为BDD人员有一点要避免完全使用单词test。

另一个极端是人们停止进行验收测试，并认为因为他们进行单元测试，所以他们的代码已经过测试。这再次是对单元测试功能的误解。我们仍然需要某种形式的验收测试。

回答

我认为被接受的答案是最弱的(测试驱动开发的缺点？)之一，也是那些可能正在编写特定测试的人的最复杂的答案。

Big time investment: for the simple
  case you lose about 20% of the actual
  implementation, but for complicated
  cases you lose much more.

TDD是一项投资。我发现，一旦我完全了解TDD，我失去的时间就很少了，而我损失的时间远远超过了维修时间。

For complex cases your test cases are
  harder to calculate, I'd suggest in
  cases like that to try and use
  automatic reference code that will run
  in parallel in the debug version /
  test run, instead of the unit test of
  simplest cases.

如果测试变得非常复杂，则可能是时候审查设计了。 TDD应该引导我们沿着较小，较不复杂的代码单元协同工作的道路

Sometimes you the design is not clear at the start and evolves as you go along - this will force you to redo your test which will generate a big time lose. I would suggest postponing unit tests in this case until you have some grasp of the design in mind.

这是他们所有人中最糟糕的一点！ TDD应该确实是"测试驱动设计"。 TDD是关于设计的，而不是测试。为了完全实现TDD带来的价值，我们需要玩具来驱动测试设计。因此，我们应该重做生产代码以使测试通过，而不是相反。

现在是目前最烦人的：测试驱动开发的缺点？

When you get to the point where you have a large number of tests, changing the system might require re-writing some or all of your tests, depending on which ones got invalidated by the changes. This could turn a relatively quick modification into a very time-consuming one.

就像公认的答案第一点一样，这似乎在测试中超出了规范，并且普遍缺乏对TDD过程的理解。进行更改时，请从测试开始。更改新代码应执行的测试，然后进行更改。如果该更改破坏了其他测试，则测试正在做他们应该做的事情，失败了。对我来说，单元测试被设计为失败的，因此为什么要先进行RED阶段，并且决不能错过。

回答

恕我直言，关于TDD的最大误解是：花费在编写和重构测试上的时间会浪费时间。这种想法就像"是的，一个测试套件很好，但是如果我们只是对其进行编码，该功能将更快地完成"。

如果正确完成，则可以在项目的整个生命周期内多次节省编写和维护测试所花费的时间，而不必花费时间调试和修复回归。由于测试成本是前期的，收益是随着时间的推移，因此很容易忽略。

其他大的误解包括忽略TDD对设计过程的影响，以及没有意识到"痛苦的测试"是一种严重的代码异味，需要迅速解决。