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

Question

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

不过,我的挫败感是,我花了很多时间来修复测试中的错误,而不是修复我的生产测试中的任何错误.

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

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

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

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

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

其他人都有这种感觉吗？

Answer 1

我觉得你在那里,这里有一些我认为在编写单元测试时更有用的东西:

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

TDD和单元测试绝对是一个真正的痛苦开始的东西,但它的其中一个变得更容易,更快,你做的越多.

Richard Dingwall的博客上有很多关于单元测试和TDD最佳实践的文章,其中很多都是关于MVC的单元测试.