关于TDD的一些常见误解是什么？

What are some common misunderstandings about TDD?

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

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

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对设计过程的影响，以及没有意识到"痛苦的测试"是一种严重的代码异味，需要迅速解决。

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

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

只是在锅中抽出另一个答案。

最常见的误解之一是您的代码是固定的，即。我有这段代码，现在我将如何测试它？如果很难编写测试，我们应该问一个问题：如何更改此代码以使其更易于测试？

为什么..？

好吧，易于测试的代码是：

模块化-每种方法都做一件事。

参数化-每个方法接受它需要的一切并输出它应有的一切。

规范明确-每种方法都能准确执行应做的工作，更多，更少。

如果我们编写这样的代码，那么测试就轻而易举。有趣的是，巧合的是，易于测试的代码是更好的代码。

更好，更易于阅读，更易于测试，更易于理解，更易于调试。这就是为什么TDD通常被描述为设计练习的原因。

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

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

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

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