2

これらのうち、統合 (リクエスト) テストを作成する「正しい」方法はどれですか。

it "should be successful" do
  get "/about/terms"
  response.should be_success
end

it "should be successful" do
  get about_terms_path
  response.should be_success
end
4

2 に答える 2

4

about_terms_pathカスタムルートパスはルートファイルで変更される可能性がありますが、ルートの名前は同じままである必要があるため、これは正しいです。

前者は脆弱なテストにつながります。

ルートの名前が変更された場合、Rails アプリ内のそのルートへのすべての参照を変更する必要があり、rspec テストも変更する必要があります。

ルートのパスが変更された場合、Rails アプリまたは rspec テストの何も変更する必要はありません。

編集：

ルートをテストしたい場合は、これをチェックしてください https://www.relishapp.com/rspec/rspec-rails/docs/routing-specs

于 2013-03-25T10:11:39.827 に答える
2

どちらでもいいと思いますが、個人的には前者の方が好きです。

統合テストは、人間の目と動作を模倣することです。人間は「/about/terms」を見ることができましたが、「about_term_path」を見ることはできませんでした。

さらに、2つの提案：

  1. JavascriptでWebドライバーを許可するCapybaraを使用することをお勧めします。その場合、「get」は機能せず、代わりに「visit」を使用します

  2. 機能テスト（コントローラ）の仕事である統合テストでのレスポンスチェックは不要です。実際のポイントに直接移動します。

追加

ジェイソンの質問に答える。はい、統合テストでは一貫してハードコードされたルートを常に使用しています。

その理由は、Acceptance Tests Driven Development のキーポイントである、 outside-in アプローチにあります。結合テストを書くとき、routes.rb がまだ改訂されていないため、名前付きルートがわかりません。または、知っているはずですが、その時点では気にしません。

rspec が「一致するルートがありません」と言ったとき、私は、コントローラーを生成して、routes.rb をチェックさせてくださいと言いました。

于 2013-03-25T13:24:09.813 に答える