2

このリクエスト仕様が正常に機能するのはなぜですか。

require "spec_helper"

describe "POST on a GET route" do
  it "should not allow this" do
    post "/applicants/new"
    assert_response :missing
  end
end

ただし、このコントローラーの仕様では、GET、POST、PUT、およびDELETEはすべて、次の場合と同じように機能します。

require 'spec_helper'

describe ApplicantsController do
  it "should not allow this" do
    post :new
    should respond_with :missing # but it responds with 200
  end
end

更新：ApplicantsControllerコードとルート定義を追加しました：

class ApplicantsController < InheritedResources::Base    
  respond_to :html
  actions :index, :new, :create

  def new
    if current_user
      redirect_to resume_application_path and return
    end

    @applicant = Applicant.new
    @applicant.applications.build
    @applicant.build_user_detail
    new!
  end    
end

ルート：

resources :applicants

更新：APIを詳しく調べて調べた結果、コントローラーの仕様はActionController :: TestCaseから継承され、リクエストの仕様はActionDispatch :: IntegrationTestから継承されるため、これは仕様によるものだと思います。コントローラ仕様の場合、HTTP動詞は単に説明的なものになります。

誰かがこれが仕様によるものであることを確認できますか？または、バグレポートを提出する必要がありますか？

ありがとうございました！

4

1 に答える 1

3

これは驚くべきことのように思えますが、コントローラーのアクションを個別にテストするという観点から見ると理にかなっています。通常、コントローラーアクションはHTTPリクエストメソッドについて知る必要はありません。メソッドなしでルートを指定すると、次のようになります。

  match 'sample' => 'applicants#index'

GET /sampleこれで、POST /sample両方ともインデックスアクションにルーティングされます。コーディングしない限り、コントローラーはGETリクエストとPOSTリクエストの違いを認識しません。コントローラの仕様では、要求メソッドとアクションの組み合わせがルーティング可能かどうかはテストされません。これは、ルーティングエンジンの責任であるためです。

ルーティング仕様で機能するルートと機能しないルートを確認できます。

it "recognizes and generates #new" do
  { :get => "/applicants/new" }.should route_to(:controller => "applicants", 
      :action => "new")
end

it "does not recognize POST /applicants/new" do
  { :post => "/applicants/new" }.should_not be_routable
end
于 2011-03-08T06:56:17.217 に答える