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

Question

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

但令我沮丧的是，我花了很多时间来修复测试中的错误，而不是修复我的生产测试中的任何错误。

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

1. 写一个存根
2. 编写测试
3. 确保测试失败
4. 填写存根
5. 测试仍然失败，所以花一些时间来检查预期和实际的输出。
6. 错误结果是在测试中，而不是实际代码。修复测试。

如果你考虑一下，这有点令人期待：单元测试涉及手动产生输出，因此容易出错;用严格的语言和良好的编码实践编写的代码具有非常自动指定的行为。

当然，有些奇怪的时候我的生产代码是测试失败的真正原因，但它确实相当罕见。

当然，没有理由完全取消单元测试;有时我完全不相信自己的代码。另一方面，我开始觉得它并不是那么有价值 - 特别是测试第一哲学。

其他人都有这种感觉吗？

Answer 1

我觉得你在那里，我在编写单元测试时发现了一些有用的东西，使它们更加坚固：

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

TDD和单元测试肯定会引发一个真正的痛苦，但它的其中一个变得更容易，更快，你做的就越多。

Richard Dingwall's blog有很多关于单元测试和TDD最佳实践的文章，其中很多都是关于MVC单元测试的。

Answer 2

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

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

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

现在这样做了一年后，团队精通测试优先方法。 @Scozzard提到了有关使用AAA /模拟框架的有效观点。

Answer 3

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