我真的应该测试控制器吗？答案

【问题标题】：Should I really test controllers?我真的应该测试控制器吗？
【发布时间】：2011-05-25 19:21:21
【问题描述】：

我正在努力获得最佳的代码覆盖/开发时间结果

目前我使用 rspec+shoulda 来测试我的模型，并使用 rspec+capybara 来编写我的验收测试。

我尝试为一个简单的 crud 编写控制器测试，但它花费的时间太长，最后我得到了一个令人困惑的测试（我可能不好）

使用 rspec 进行控制器测试的最佳实践是什么？

这是我的测试和控制器的要点（一个测试尚未通过）：

https://gist.github.com/991687 https://gist.github.com/991685

【问题讨论】：

标签： ruby-on-rails ruby rspec bdd

【解决方案1】：

也许不会。

当然，您可以为您的控制器编写测试。它可能有助于编写更好的控制器。但如果你的控制器中的逻辑很简单，那么你的控制器测试就不是胜利的地方。

我个人更喜欢经过良好测试的模型和一套完整的集成（验收）测试，而不是控制器测试。

也就是说，如果您在为控制器编写测试时遇到问题，那么一定要测试它们。至少在你掌握它之前。然后决定是否要继续。每种测试都一样：尝试直到你理解它，然后再决定。

【讨论】：

我接受 rspec/capybara 和 unit 仅适用于模型。我喜欢接受是你不测试实现。您测试功能，实现可能会更改，功能仍然存在，测试仍然会通过。顺便说一句，我发现黄瓜规格很难维护，我更喜欢纯 Ruby。

【解决方案2】：

我对此的看法是验收测试（即 Cucumber / Capybara）测试用户通常会在应用程序上执行的交互。这通常包括用户是否可以使用有效数据创建特定资源，然后如果他们输入 invalid 数据，他们是否会看到错误。控制器测试更多是针对用户不应该正常执行的事情，或者对于使用 Cucumber 进行测试过于繁琐的极端情况。

通常当人们编写控制器测试时，他们实际上是在测试相同的东西。在控制器测试中测试控制器方法的唯一原因是针对边缘情况。

边缘情况，例如，如果用户在显示页面中输入了无效的 ID，他们应该会看到 404 页面。这是使用控制器测试进行测试的一种非常简单的事情，我建议这样做。您要确保当他们点击操作时收到 404 响应，非常简单。

确保您的 new 操作成功响应并且没有语法错误？请。这就是您的 Cucumber 功能会告诉您的。如果操作突然发展为 糟糕的情况，您的功能将中断，然后您将修复它。

另一种思考方式是您是否想测试特定操作以某种方式响应（即控制器测试），或者您是否更关心用户可以执行该new 操作并实际执行创建该资源的整个动作（即验收测试）？

【讨论】：

您已经有一段时间没有发布它了。从那以后你的看法有什么变化吗？或者这篇文章仍然是 100% 与您的观点保持同步的 :)
这个回复虽然年代久远，但我还是非常赞同。

【解决方案3】：

编写控制器测试可以让您的应用程序对您撒谎。一些原因：

控制器测试不在它们运行的环境中执行。也就是说，它们不在机架中间件堆栈的末尾，因此在使用设计时用户不可用（作为一个简单的示例）。随着 Rails 越来越多地转向基于机架的设置，使用的机架中间件越来越多，您的环境越来越偏离“单元”行为。
您不是在测试应用程序的行为，而是在测试实现。通过模拟和存根，您正在以规范的形式重新实现实现。一种简单的方法来判断您是否正在这样做；如果您不更改 url 响应的预期行为，但确实更改了控制器的实现（甚至可能映射到不同的控制器），您的测试会中断吗？如果他们这样做，那么您正在测试实现而不是行为。你也在让自己被骗。当您进行 stub 和 mock 时，无法保证您设置的 mock 或 stub 会按照您的想法执行，或者即使它们假装的方法在重构发生后仍然存在。
无法通过应用程序的“公共”API 调用控制器方法。到达控制器的唯一方法是通过堆栈和路由。如果你不能通过 url 从请求中破解它，它真的坏了吗？

我使用我的测试来保证我的应用程序在部署时不会中断。控制器测试并没有增加我对我的应用程序确实可以运行的信心，实际上它们的存在降低了我的信心。

另一个例子，在测试你的应用程序的“行为”时，你是否关心某个特定的文件模板是否被渲染，或者是否引发了某个异常，或者你的应用程序的行为是否会将一些东西返回给具有特定状态代码的客户端？

测试控制器（或视图）会增加您对自己施加的测试负担，这意味着重构的成本高于所需的成本，因为可能会破坏测试。

【讨论】：

【解决方案4】：

你应该测试吗？是的

有些宝石可以让测试控制器更快

http://blog.carbonfive.com/2010/12/10/speedy-test-iterations-for-rails-3-with-spork-and-guard/

【讨论】：

【解决方案5】：

一定要测试控制器。一些痛苦的经验法则：

模拟模型对象
您的控制器操作使用的存根模型对象方法
牺牲很多鸡。

【讨论】：

嗨！如果要使用换行符来制作列表，则需要在每行的末尾有 2 个空格。在我看来，更容易和更易读的是在每一行之前添加*——我编辑了你的帖子，所以你可以看看。如果您不喜欢它，请随意回滚 :-)
控制器中没有什么要测试的，逻辑应该在模型、服务等中。

【解决方案6】：

我喜欢对每个控制器方法进行测试，至少只是为了消除可能导致页面崩溃的愚蠢语法错误。

【讨论】：

【解决方案7】：

很多人似乎正在转向使用 Cucumber 进行集成测试来代替编写控制器和路由测试的方法。

【讨论】：