替代rails集成测试的控制器测试应该始终坚持db？

我正在发现与测试流相关的Rails集成测试，并且我有一些关于使用集成测试替换控制器测试（在rails 5中不推荐使用）的行业标准的问题。替代rails集成测试的控制器测试应该始终坚持db？

通常我们有微小的控制器，我们可以获取参数，调用正确的协作者并准备响应，并且很容易通过直接在控制器对象上嘲讽协作者来测试它。

我很担心将每个控制器测试迁移到集成测试的开销，而持久化db。这种情况的标准是什么？

只测试一条路线/动作而不是完整流程时的标准是什么？

我们怎么能代替这个?:

@controller.stubs(:authenticate).returns(true)

集成测试旨在模仿真实用户。他们打算全面测试整个应用程序。

意见因此而异。对我而言，这意味着你应该完全避免嘲弄/嘲笑。没有一件事情被嘲讽或嘲笑，一切都完全执行。这意味着我编写的每个集成测试都要通过输入用户名和密码的实际身份验证过程。有些步骤是多余的，是的。

集成测试比单元/控制器测试更慢。切断验证步骤可能不会为您节省足够的时间从长远来看有所作为（无双关语意图）。