假设我有一个命名小部件的列表。在我的测试代码的某个地方，我想验证一下
widget = FactoryGirl.create(:widget)
get :index
生成一个页面，其中包含字符串#{widget.name}。
我的问题：我是把它写成控制器测试还是集成测试？
（除了#1：这似乎超出了控制器测试的范围，因为它假设知道呈现什么视图。但是将其编写为集成测试感觉太重了，因为它只需要一个请求/ 响应事务。）
（除了 #2，我的一般问题是“您如何决定控制器测试中的内容以及集成测试中的内容？”但这对于堆栈溢出问题来说可能过于宽泛。）
【问题讨论】：
标签： ruby-on-rails-3 unit-testing rspec integration-testing
有时我认为 Stack Overflow 应该授予 RTFM 徽章，我应该是第一个获得它的人！
深入研究后，我发现 RSpec 支持专门用于测试渲染内容的“查看规范”——这正是我最初的问题所在。
测试在 spec/views/ 中编写。 Documentation and examples can be found here，但请务必查看您当前版本的 RSpec 的文档。
【讨论】：
我认为这些不同类别的测试没有任何普遍认可的定义，但我个人将其称为“请求规范”，一种集成测试，但仅涉及单个请求/响应循环。它显然不仅仅是一个控制器测试，因为它涉及 MVC 架构的所有元素。另一方面，您不会四处点击然后查找按钮、单击它们等，所以这不是我通常认为的“集成测试”。
区分我所说的“请求规范”和您通常所说的“集成测试”的一种简单方法是使用get（来自ActionDispatch）与visit（来自capybara）。如果您只使用get（和post 等），那么它是一个请求规范。如果您使用的是visit，那么这是一个集成测试。
有关get 和visit 之间区别的更多信息，请参阅此帖子：http://blog.plataformatec.com.br/2012/06/improving-the-integration-between-capybara-and-rspec/ 在该帖子中，有一个建议完全摆脱 spec/requests 并用 spec/api 替换它（我将调用“请求规范”）和规范/功能（我称之为“集成测试”）。
无论如何请注意，我上面写的只是我个人看待这种区别的方式，其他人可能不同意。
【讨论】：
get 或Capybara 的visit（尽管不在单个测试中）。相反，我问的是控制器与 [request |集成] 测试。
get 和 visit 不可互换，至少从某种意义上说，您不能在这里用visit 替换get，反之亦然，并期望测试有效. （在发出get 请求后尝试使用fill_in。）虽然我同意两者都是真正的集成测试，但有一个重要的区别 - 正如我链接到的帖子所解释的那样，这种区别引起了混乱。