我刚刚开始一个新项目,现在ASP.NET MVC以非常可组合的方式设计,我认为可能是开始单元测试的好时机.我的代码大部分是新鲜的,在编写实际的生产代码之前,我正在编写测试.
不过,我的沮丧是,我花更多的时间修复我的测试中的错误,而不是修改我的生产测试的错误.
我的典型工作流最终是这样的：
>写一个存根
>写测试
>确保测试失败
>填入存根
>测试仍然失败,所以花费一段时间超过预期和实际的产出.
>错误原来在测试中,而不是实际的代码.修复测试.
如果你想到这一点,这是有点预期的：单位测试涉及到手工生产,所以是容易出错的;以严格语言编写的代码和良好的编码实践的代码具有非常自动的规定.
当然,当我的生产代码是测试失败的实际原因时,奇怪的是,这真是比较少见.
当然没有理由完全消除单元测试;有时我根本就不信任我自己的代码.另一方面,我开始觉得这不是那么有价值 – 尤其是考验的哲学.
有人有这样的感觉吗？
我觉得你在那里,这里有几件我发现在编写单元测试时有用的东西,使它们更加坚实：
>如果您还没有,请尝试将每个测试的单元测试分解为一个断言.您可能需要对每个代码进行许多断言,以便您的测试方法很大(这可能意味着您的方法也应该被分解).但是这样做会使您的单元测试松动,并且使它们更不容易耗时. Theres是一个很好的模式,实施称为Arrange,Act Assert (AAA)
>确保您的单元测试完全隔离,即在代码之外没有互动或通话,即数据库,Web服务等.
>使用可用的框架,使您的单元测试体验更容易,并为您做大部分工作,例如Nbuilder打开对象列表和Moq来嘲笑测试所需的对象.
>如果还没有,请使用test fixtures,以便您不必为每个测试设置所有内容.
TDD和单元测试绝对是一个从屁股真正痛苦开始的东西,但是其中的一件事更容易,更快速地完成了您的工作.
Richard Dingwall’s blog有不少关于单元测试和TDD的最佳实践的文章,其中有许多关于使用MVC进行单元测试的文章.
