关于 TDD 有哪些常见的误解？答案

【问题标题】：What are some common misunderstandings about TDD?关于 TDD 有哪些常见的误解？
【发布时间】：2008-09-16 13:25:06
【问题描述】：

阅读对这个问题Disadvantages of Test Driven Development? 的回复后，我的印象是对什么是 TDD 以及应该如何进行有很多误解。在这里解决这些问题可能很有用。

【问题讨论】：

标签： tdd

【解决方案1】：

我觉得被接受的答案是最弱的答案之一 (Disadvantages of Test Driven Development?)，而且最上调的答案闻起来可能是某个人可能正在重写指定的测试。

大时间投资：为简单万一你损失了大约 20% 的实际金额实施，但对于复杂的损失更多。

TDD 是一项投资。我发现一旦我完全投入到 TDD 中，我失去的时间是非常非常少的，而在维护时间方面，我失去的时间比弥补的要多。

对于复杂用例，您的测试用例是更难计算，我建议尝试和使用这样的案例将运行的自动参考代码在调试版本中并行 / 测试运行，而不是单元测试最简单的情况。

如果您的测试变得非常复杂，可能是时候审查您的设计了。 TDD 应该会引导您走上更小、更简单的代码单元协同工作的道路

有时您的设计在开始时并不清楚，并且随着您的进行而发展 - 这将迫使您重新进行测试，这将导致大量时间损失。在这种情况下，我建议您推迟单元测试，直到您对设计有所了解。

这是最糟糕的一点！ TDD 真的应该是“测试驱动的设计”。 TDD 是关于设计，而不是测试。要充分实现 TDD 优势的价值，您必须从测试中驱动您的设计。所以你应该重做你的生产代码以使你的测试通过，而不是像这一点建议的那样反过来

目前更新最多的：Disadvantages of Test Driven Development?

当您有大量测试时，更改系统可能需要重新编写部分或全部测试，具体取决于哪些测试因更改而失效。这可能会将相对较快的修改变成非常耗时的修改。

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

【讨论】：

【解决方案2】：

恕我直言，关于 TDD 的最大误解是：花在编写和重构测试上的时间会浪费掉。这种想法就像“是的，测试套件很好，但功能会很完整如果我们只是编码的话，速度会更快”。

如果做得好，编写和维护测试所花费的时间会在项目的生命周期中节省多次而不是花费在调试和修复回归上。由于测试成本是预先支付的，而且收益是随着时间的推移而产生的，因此很容易被忽视。

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

【讨论】：

我同意您关于花费时间与损失时间的观点。我发现当我可以使用测试框架和 TDD 时，我可以更快地编写代码。它让我专注于任务，并准确地告诉我我在哪里犯了错误。我花在挠头上的时间少了很多。

【解决方案3】：

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

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

【讨论】：

【解决方案4】：

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

测试通常会取消有缺陷的需求，因此，开发人员生产的产品不能满足用户的期望。在我看来，TDD 的关键是与用户一起定义需求，同时帮助管理他们的期望。

【讨论】：

如果您是根据有缺陷的需求工作，那么没有任何开发过程可以帮助您。这不是对 TDD 的误解。

【解决方案5】：

在我看来，这些问题颇有争议，因此容易产生误解：

根据我的经验，最大的优势是以花费大量时间编写测试为代价生成更好的代码。因此，对于需要高质量的项目来说，这确实是值得的，但在其他一些质量不高的网站上，额外的时间将不值得。
人们似乎认为只需要测试主要功能子集，但恕我直言，这实际上是错误的。您需要对所有内容进行测试，以使您的测试在重构后有效。
TDD 的一大缺点是不完整的测试会产生错误的安全感：我见过一些网站宕机，因为人们认为单元测试足以触发部署。
不需要模拟框架来执行 TDD。它只是一种以更简单的方式测试某些案例的工具。最好的单元测试虽然在堆栈中处于高位，但应该与代码中的层无关。在这种情况下，一次测试一层是没有意义的。

【讨论】：

【解决方案6】：

只是把另一个答案扔进锅里。

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

为什么..？

那么容易测试的代码是：

模块化 - 每个方法只做一件事。
参数化 - 每个方法都接受它需要的一切并输出它应该输出的一切。
很好地指定 - 每个方法都完全按照它应该做的，不多也不少。

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

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

【讨论】：