假设我有一个命名小部件的列表。在我的测试代码的某个地方，我想验证
widget = FactoryGirl.create(:widget)
get :index
生成一个页面，其中某处包含字符串#{widget.name}。
我的问题：我是把它写成控制器测试还是集成测试？
（除了＃1：这似乎超出了控制器测试的范围，因为它假设知道呈现什么视图。但是将其编写为集成测试感觉太重了，因为它只需要一个请求/响应事务。）
（除了＃2，我的一般问题是“你如何决定控制器测试中的内容以及集成测试中的内容？”但这对于堆栈溢出问题来说可能过于宽泛。）
有时我认为 Stack Overflow 应该授予 RTFM 徽章，我应该是第一个获得它的人！
进一步挖掘，我发现 RSpec 支持专门用于测试渲染内容的“查看规范”——这正是我最初的问题所在。
测试在 spec/views/ 中编写。 可以在此处找到文档和示例，但请务必查看您当前版本的 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/在那篇文章中有一个建议完全摆脱规范/请求，并将其替换为规范/API（我称之为“请求规范”）和规范/功能（我称之为“集成测试”）。
无论如何请注意，我上面写的只是我个人看待这种区别的方式，其他人可能不同意。