asp.net mvc 控制器动作测试答案

【问题标题】：asp.net mvc controller actions testingasp.net mvc 控制器动作测试
【发布时间】：2010-05-16 09:53:32
【问题描述】：

我只是想知道其他人如何在 asp.net mvc 中测试控制器操作？我的大部分依赖项都被注入到我的控制器中，因此操作方法中的逻辑数量并不多，但可能会有一些条件逻辑，例如我认为这是不可避免的。

过去我为这些操作方法编写了测试，模拟了依赖关系并测试了结果。我发现这是非常脆弱的，并且需要维护一个真正的 PITA。到处都有“期望”和“存根”方法很容易破坏，但我看不到任何其他测试控制器操作的方法。

我实际上认为手动测试其中一些可能更容易！有人有什么建议吗？也许我在这里遗漏了什么？

谢谢

伊姆兰

【问题讨论】：

【解决方案1】：

我认为我没有为控制器编写单个测试，因为我的所有逻辑都在其他地方。就像你说的那样，控制器中的代码量最少，而且其中的任何逻辑都非常简单，以至于它真的不具备完整的测试策略。

我更喜欢为我的模型提供大量测试以及任何支持代码，如 DTL 和数据层等。

我想我已经看到一些人模拟他们的 copntollers，传入预期的模型并查看结果输出，但我不确定这给了你多少。

我认为如果我要测试一个控制器，我只会真正测试发布操作，以确保提供给我的控制器的内容是我在我的模型中得到的内容以及测试（安全性）。但后来我在许多不同级别的地方都有安全保障。

但是集成测试不仅仅是功能性的。就像我之前说的那样，我在其他地方做的功能。

再一次，如果它值得写，那么它值得测试，对吧？我想您需要确定易碎位的位置和位置，以及您希望如何测试它们。

【讨论】：

我同意，我看过一些关于 TDD 与控制器的示例和博客，并且一直想知道您实际上从中获得了多少收益。我完全支持 TDD，但在为将大部分工作交给其他组件的控制器编写测试时感觉有些不对。我同意这些确实是集成测试。我考虑这个的主要原因是为了简化回归测试。如果我对站点进行更改，我会进行通常的单元测试，但也有可能在此过程中某些视图或控制器可能已损坏。目前看来我将手动进行测试。
控制器中总是有一些逻辑，或者为什么有它们？我会测试你写的 is 的逻辑。例如，它将正确的工作交给正确的组件并停在那里。
没错，但是我发现这种基于交互的测试非常脆弱。我想我可能会将控制器测试限制在异常处理和参数验证之类的事情上，作为一种折衷方案。或者我想只测试调用了正确的组件就足够了，而不是对调用它们的参数设置特定的期望等。