11

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

4

6 回答 6

13

我觉得公认的答案是最弱的答案之一（测试驱动开发的缺点？），而且最上调的答案是可能正在编写指定测试的人的味道。

大时间投资：对于简单的情况，你会损失大约 20% 的实际实现，但对于复杂的情况，你会损失更多。

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

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

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

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

这是他们中最糟糕的一点！TDD 真的应该是“测试驱动设计”。TDD 是关于设计，而不是测试。要充分实现 TDD 优势的价值，您必须通过测试来驱动您的设计。因此，您应该重做您的生产代码以使您的测试通过，而不是正如这一点所暗示的那样

现在更新最多的：测试驱动开发的缺点？

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

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

于 2008-09-16T13:42:35.597 回答
5

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

如果处理得当，编写和维护测试的时间可以在项目的整个生命周期内多次节省，而不是花费在调试和修复回归上的时间。由于测试成本是预先支付的，而回报是随着时间的推移而产生的，因此很容易被忽视。

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

于 2008-09-16T13:48:14.570 回答
1

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

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

于 2008-09-16T13:37:29.010 回答
0

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

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

于 2008-09-16T13:29:07.360 回答
0

这些是我认为颇具争议并因此容易产生误解的问题：

  • 以我的经验，最大的优势是以花费大量时间编写测试为代价生成更好的代码。因此，对于需要高质量的项目来说，这确实是值得的，但在其他一些以质量不高的网站上，额外的时间将不值得付出努力。

  • 人们似乎认为只需要测试功能的主要子集，但恕我直言，这实际上是错误的。您需要测试所有内容，以使您的测试在重构后有效。

  • TDD 的一大缺点是不完整的测试带来的错误安全感：我见过一些网站宕机，因为人们认为单元测试足以触发部署。

  • 不需要模拟框架来执行 TDD。它只是一种以更简单的方式测试某些案例的工具。最好的单元测试虽然在堆栈中处于高位，但应该与代码中的层无关。在这种情况下，一次测试一层是没有意义的。

于 2008-09-16T13:35:37.830 回答
0

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

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

为什么..？

那么易于测试的代码是：

  1. 模块化 - 每种方法都做一件事。
  2. 参数化 - 每个方法都接受它需要的一切并输出它应该输出的一切。
  3. 明确规定——每种方法都完全按照它应该做的，不多也不少。

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

Better as in easier to read, easier to test, easier to understand, easier to debug. This is why TDD is often described as a design exercise.

于 2011-04-12T08:55:31.463 回答