我意识到我不明白为什么 Rails Controller 测试/规范的结构是这样的。
在编写 Controller 测试时，我们被鼓励或多或少地将 Controller 视为一个单元并相应地编写单元测试，只关心 Controller 的输入和输出。例如，我们设置数据库的特定状态，也许 stub 一些 Devise 方法来模拟用户登录，当我们调用 post :create 或其他任何方法时，我们附加发送的参数的散列到那个 Controller Action 。
然后，对于输出，我们查看数据库的结果状态，我们检查响应 HTTP 代码和重定向等，以及将传递给模板渲染过程的任何分配变量。
Controller 只是一个 Ruby 类，它的公共(public)方法被调用以执行各种 RESTful 操作。所以在 Controller 规范中，我们不会加载像 /kittens/new 这样的 URL；相反，我们直接调用 Controller 操作，例如 get :new。路线不应该是相关的；它们只是系统的另一部分，决定为给定请求调用哪个 Controller 操作。
那么为什么我们必须指定 HTTP 方法(如 get、post、put、delete ) 调用 Controller 操作时？这不是一个外部细节，是路由工作原理的一部分吗？
出于好奇，我采用了我的一个 Controller 规范并切换了所有这些方法，最终得到了诸如 delete :show 和 get :create 之类的东西。 没有损坏。所以我很困惑:如果这些方法与我们在 Controller 规范中测试的代码没有相关细节，为什么我们要区分这些方法？
最佳答案
我不太确定这是否就是它仍然存在的原因，但在 REST 之前，许多应用程序使用相同的端点进行 new 和 create。 (比如，你可能有一个带有 new_review Action 的 Controller ，如果你用 GET 击中它，它会显示评论表单，如果你击中它POST，它会保存评论。)在这些 Controller 操作中，您会看到 if request.post?。
如今，您很少看到它(谢天谢地)，但它仍然受到支持。因此，通过将 HTTP 方法放入测试中，您可以确保 request 对象的行为符合您在 Controller 操作中的预期方式。
关于ruby-on-rails - 在编写 Rails Controller 测试时，为什么使用#post vs #get vs #delete？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/28289921/