加速ASP MVC单元测试

MSTEST的问题不是运行速度本身,而是测试环境本身。您可以使用Resharper运行MSTEST测试,而且速度非常快。我的测试运行在一个存储库接口上,当调用控制器时,我模拟一个内存中的存储库。

也就是说,控制器测试应该非常简单:返回类型(viewresult、jsonresult)和模型类型。没什么别的(见 http://www.arrangeactassert.com/how-to-unit-test-asp-net-mvc-controllers/ )独立于控制器测试业务层呼叫。如果做得正确,一千个单元测试只需要几秒钟就可以完成。

您看到的大多数速度冲击都是MStests在每次运行一个测试时都会启动ASP.NET开发服务器。

我将尽可能多的应用程序保存在单独的库中 外部 我的ASP.NET应用程序,以便它们可以独立进行单元测试。这样可以避免在单元测试期间触发ASP.NET开发服务器时受到的冲击。

当模拟控制器时,我看不到任何原因,为什么您不能删除告诉测试系统启动开发服务器的属性。毕竟,模仿的全部目的不是为了去掉“外部”组件吗?

同样,为模型使用存储库的全部目的是为了让您可以注入模拟对象进行测试。这些测试也不需要开发服务器。

就视图而言,我不会为它们编写单元测试。尽可能薄些,并通过目视检查手动测试。

可以为包括ASP.NET开发服务器的模型和控制器包括一组不同的测试。这些测试将是集成测试套件的一部分。

更改单元测试框架对您没有任何好处

如果测试花费的时间太长,主要是因为它们连接到数据库或Web服务…

我建议您使用一个CI来运行所有的测试,并且将测试分开,例如,UI层应该将其测试与数据访问测试分开…

测试速度受多个因素的影响——MSTEST实际上可能只是其中之一。

以下任何一项都可能对测试速度产生影响:

• 实际执行数据库访问的测试
• 依赖于磁盘访问的测试(例如,读取web.config)
• 代码是 事实上 断开(例如,执行无数不必要的循环、其他性能漏洞)
• 测试做得太多(一次测试几件事情)或没有真正测试一个单元

根据定义,单元测试应该小而快。除了你的框架之外,在上面的列表中寻找其他可能会减慢速度的东西。