我应该测试我的控制器(MVC)吗？

Question

我已经使用TDD几个月了,现在我想学习如何测试我的控制器(MVC).

通过测试每个功能的最小单元来进行单元测试.有时,控制器不小.他们从模型中获取数据并传递给视图.

我应该如何对控制器进行单元测试？我应该模拟控制器的依赖吗？

控制器测试是否考虑集成测试？

谢谢.

Answer 1

我正在做TDD很长一段时间.我正在使用ASP.NET MVC进行TDD超过一年.

我从规范规则开始:"没有单元测试的代码行",所以我测试了所有东西 - 包括控制器.必须对控制器进行测试,这是MVC框架的目标之一 - 使这些东西可测试.

对于小型应用程序,该方法非常有效.几乎所有逻辑都放在控制器内部,一切都经过了很好的测试.

但只要我继续使用MVC,我就开始改变主意了.我尽量让控制器保持苗条.理想情况下,只需将调用委托给某个业务对象并包装结果.其余的是过滤器.

这对我来说也很好用!我现在拥有单独实现/测试的业务对象,因此控制器只是集成点.没有理由测试集成点,因为它很小.

关于集成测试:我还没有遇到过我真正需要的情况.不要忘记,控制器总是依赖于构造函数注入的抽象.只要您对这些抽象如何工作有"好"的假设,就可以创建适当的单元测试.当您失败时,您只需更正单元测试.

集成测试很重要且有用,但我尝试尽可能少地创建它们.

Answer 2

我采用与Alexander B相同的控制器方法.我的控制器很薄而且笨.但是,我仍然为它们编写测试,以确保它们正确调用业务或服务对象并传递正确的参数.

上周我最终抓到的一个实际错误可能最好地说明了这一点.我有一个允许管理员批准或拒绝用户请求的控制器,它有两个视图,一个未完成请求的列表视图和每个请求的详细信息视图.两种观点都可以批准或否认.控制器调用的服务有一堆其他公开的方法,包括一个用于更改请求状态的方法......您可以看到它的发展方向.列表视图称为批准或拒绝并触发工作流的正确方法,详细信息视图仅调用更改状态方法,并且未启动任何进一步的工作流.这是我的编码错误,但对于我的生活我多年都看不到它 - 工作流在后台线程中运行,我花了一个星期的时间在这些线程中运行,假设它在该部分中是错误的.

所以对我来说

• 一旦您的控制器将数据传递到其他地方,它就需要进
• 如果你的控制器检查模型的有效性,它需要测试(如果有人删除了支票怎么办？)

等等

Answer 3

昨天问了同样的问题：

测试控制器有意义吗

在我看来 - 是的，测试控制器确实有意义。你可以：

• 它们背后的模拟服务，因此更容易测试控制器本身
• 保持服务不被模拟并进行集成测试