单元测试中的错误多于生产代码中的错误答案

【问题标题】：More bugs in unit tests than in production code单元测试中的错误多于生产代码中的错误
【发布时间】：2011-03-16 05:06:30
【问题描述】：

我刚刚开始了一个新项目，现在 ASP.NET MVC 以极其可组合的方式设计，我认为现在可能是开始进行单元测试的好时机。我的大部分代码都是新鲜的，我在编写实际生产代码之前先编写测试。

不过，令我感到沮丧的是，我花更多的时间来修复测试中的错误，而不是修复生产测试中的任何错误。

我的典型工作流程最终是这样的：

如果您考虑一下，这在某种程度上是意料之中的：单元测试涉及手动生成输出，因此容易出错；用严格的语言编写并具有良好编码实践的代码具有非常自动指定的行为。

当然，有时我的生产代码是测试失败的真正原因，但这种情况确实比较少见。

当然，没有理由完全消除单元测试；有时我根本不相信自己的代码。另一方面，我开始觉得这并不是那么有价值——尤其是测试优先的哲学。

还有其他人有这种感觉吗？

【问题讨论】：

【解决方案1】：

我觉得你在那里，以下是我在编写单元测试以使它们更可靠时发现的一些有用的东西：

如果还没有，请尝试将单元测试分解为每个测试一个断言。如果方法很庞大，您可能必须对每个代码单元进行许多断言，以测试方法（这可能意味着您的方法也应该被分解）。但这会放松你的单元测试，使它们不太容易进行耗时的维护。有一个很好的模式可以付诸实践，叫做Arrange, Act Assert (AAA)
确保您的单元测试完全隔离，即在您的代码（即数据库、Web 服务等）之外没有任何交互或调用。
使用可用的框架让您的单元测试体验更轻松，并为您完成大部分工作，例如，Nbuilder 破解对象列表，Moq 模拟测试所需的对象。
如果您还没有，请使用 test fixtures，这样您就不必为每个测试设置所有内容。

TDD 和单元测试绝对是一开始就让人头疼的事情，但它是其中之一，你越坚持，它就越容易和更快地完成。

Richard Dingwall's blog 有很多关于单元测试和 TDD 最佳实践的文章，其中许多实际上是关于使用 MVC 进行单元测试的。

【讨论】：

【解决方案2】：

首先，TDD 需要时间来适应。

我们作为一个团队在一年前开始使用 TDD。最初，我们首先编写代码（类/单个模块），然后编写覆盖该代码的测试。

然后我们开始编写与代码并行的测试（编写一个方法/一组方法，然后编写覆盖这些方法的测试用例）。在此期间，我们使用覆盖率工具来检查我们的覆盖率。

现在经过一年的努力，团队已经精通测试优先方法。 @Scozard 提到了有关使用 AAA / 模拟框架的有效要点。

【讨论】：

【解决方案3】：

如果您的测试将实际结果与手写的预期值（偶尔输入错误）进行比较，您可能只需重构测试即可获得一些成果。不要验证方法 X 返回的实例是否与测试实例相同，而是验证方法返回的实例是否具有与测试实例相同的重要属性。

【讨论】：