MVC优势

我的应用程序已经具备了领域层单元测试，我想知道什么是单元测试控制器的优点/缺点MVC优势

和测试控制器时，应该写什么测试用例。

由于

2010-12-02 Snehal

这要看情况。

验证，重定向，临时消息等可能发生在控制器中。你可能会认为这些操作应该像你的模型那样进行测试。

另一方面，你应该瞄准'Fat Model, Skinny Controller'的心态。我倾向于确保我的控制器尽可能愚蠢。围绕您关心的功能（硒，黄瓜等）进行一些端到端的测试，这些将强制您的控制器是正确的。假设我们正在开发一个列出一些项目的功能。如果此功能的端到端测试正常，则控制器正常。如果这个打破了，你会知道你已经引入了一个回归。结合这一点，我只有测试，检查正确的意见呈现和正确的响应发生 - 重定向，JSON等...任何more testing on your controller和你有错误的地方的逻辑。

在Steve Sanderson的ASP.NET MVC2中，他对上述推理提出了一些优异的观点。我完全推荐它。没有这些简单的控制器测试是我可以轻松打开您的代码库，做一个简单的改变，并打破你的应用程序。只要正确的观点/回应发生，应用程序仍然会在功能上保持完好。

我应该补充一点，测试一个服务在控制器中被调用，正确的参数是如此的微不足道，而且你可以快速做到这一点，不管你是否间接测试你的控制器。我倾向于总体上赞成这种方法。所以你的问题的完整答案是肯定的，测试你的控制器;）

来源

2010-12-02 19:18:58 Finglas

A'Pro的思想：

在要传递量化的数据或参数从控制器到视图的情况。

在某些情况下，虽然我会认为有限或罕见，但要测试控制器内部不受支持代码测试覆盖的内部逻辑。虽然可以认为应该移动这些代码段。

A“精读”思想：

如果你的控制器测试没有增加任何额外的代码覆盖率或者是重复的测试覆盖率，它只是开销和增加开发时间没有好处。

来源

2010-12-02 19:01:02

尽管您应该始终努力将业务逻辑控制在控制器之外，但通常情况下，视图模型的构建可能非常复杂以至于很容易进行测试。

例如，当通过多个选择菜单显示视图时，这些菜单通过自定义视图模型对数据库进行复杂的linq查询。这种逻辑不是业务逻辑，因此将其放入业务层似乎并不正确。另一方面，它需要进行测试。

编辑：为了澄清，我不是说选择查询在你的看法。这将验证MVC模式。我的意思是一个控制器，它执行这样的查询并用视图显示的结果构建复杂的自定义视图模型。

来源

2010-12-02 19:07:04

该视图应该不知道您的查询是什么 - 结果是。视图不应该与数据库绑定在一起。 – Finglas 2010-12-02 19:15:20

有些东西，可能是在控制器的行动值得测试：即获取视图模型返回（如知名度，下拉列表值等）

重定向

UI逻辑（例如登录的用户将主页重定向至其他网页，而不是）
验证/警报

来源

2010-12-02 19:13:15

我发现测试控制器的问题之一是，在一些情况下，你必须模仿ASP.NET MVC遵循真正的执行链测试你的控制器。

例如，如果在OnExecuting方法中有代码，则需要找到一种方法来在单元测试期间执行控制器中的实际操作方法时触发该方法。

来源

2010-12-02 20:52:41

回答

相关问题