unit-testing - 单元测试中的错误比生产代码中的错误更多

Question

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

然而，我的挫败感在于，与修复生产测试中的任何错误相比，我在测试中修复错误的时间要多得多。

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

写 stub

写测试

确保测试失败

填写 stub

测试仍然失败，所以花一些时间检查预期和实际输出。

结果证明错误出在测试中，而不是实际代码中。修复测试。

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

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

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

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

Answer 1

我觉得你在那里，在编写单元测试以使其更可靠时，我发现以下几件事很有用:

如果您还没有，请尝试将单元测试分解为每个测试一个断言。如果方法很庞大，您可能必须对每个代码单元进行许多断言以进行测试(这可能意味着您的方法也应该分解)。但这将放松您的单元测试并使它们不太容易进行耗时的维护。有一个很好的模式可以付诸实践，叫做 Arrange, Act Assert (AAA)

确保您的单元测试是完全隔离的，即在您的代码(即数据库、Web 服务等)之外没有交互或调用。

使用可用的框架使您的单元测试体验更轻松并为您完成大部分工作，例如，Nbuilder修改对象列表和 Moq模拟出你需要测试的对象。

如果您还没有，请使用 test fixtures所以你不必为每个测试设置一切。

TDD 和单元测试绝对是开始真正痛苦的事情之一，但它是其中之一，你越坚持，做起来就越容易、越快。

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