2017-10-17 9 views
1

これはDockerを使った非常に基本的なRails 5アプリケーションです。これには、Deviseなどを使用せずにゼロから構築したユーザー認証が含まれています。今、私はCapybaraで要求仕様について学びたいと思っていますが、私はそれにはかなり奇妙な問題のように思えます。Capybaraでのリクエスト、POST時には

<%= form_tag sessions_path do %> 
      <form class="m-t" role="form" action="/"> 
       <div class="form-group"> 
       <%= text_field_tag :email, params[:email], class: 'form-control', placeholder: "Email Address", required: "" %> 
       </div> 
       <div class="form-group"> 
       <%= password_field_tag(:password, nil, class: 'form-control', placeholder: "Password", required: "") %> 
       </div> 
       <div class="form-group"> 
         <%= check_box_tag :remember_me, 1, params[:remember_me] %> 
         <%= label_tag :remember_me %> 
         </div> 
       <div class="actions"><%= submit_tag "Log In", class: "btn btn-primary block full-width m-b" %></div> 
      </form> 
     <% end %> 

そして、私のrequests/sessions_spec.rb

はここに私のログインフォーム(sessions.new.erb)だ今

require "rails_helper" 

RSpec.feature "Login", :type => :feature do 
    scenario "handles wrong email and password gracefully" do 
    visit login_path 
    fill_in "Email Address", :with => "something" 
    fill_in "Password", :with => "something" 
    click_button "Log In" 

    expect(page).to have_text("Email or password incorrect") 
    end 
end 

、これはあなたがそれを手動でテストした場合ので、私はカピバラは同じものを見ることが推測だろう動作します。しかし、それは失敗し続けた。保護されたコントローラにアクセスしようとすると、ログインしていないと、/loginにリダイレクトされ、Please log in to see this pageというメッセージが点滅するようにアプリケーションが構成されています。 Rspecテストはそれを返すものでした。それはカピバラが別のページを訪問しようとしていたことを示唆しました。最初のビットは、ログインが新しいSessionsController#で大丈夫処理され、GETされ

Started GET "/login" for 127.0.0.1 at 2017-10-17 06:59:26 +0000 
Processing by SessionsController#new as HTML 
    Rendering sessions/new.html.erb within layouts/empty 
    Rendered sessions/new.html.erb within layouts/empty (1.1ms) 
Completed 200 OK in 6ms (Views: 6.1ms | ActiveRecord: 0.0ms) 
Started GET "/?email=something&password=[FILTERED]&commit=Log+In" for 127.0.0.1 at 2017-10-17 06:59:26 +0000 
Started GET "/locations" for 127.0.0.1 at 2017-10-17 06:59:26 +0000 
Processing by LocationsController#index as HTML 
Redirected to http://www.example.com/login 
Filter chain halted as :authenticate rendered or redirected 
Completed 302 Found in 2ms (ActiveRecord: 0.0ms) 
Started GET "/login" for 127.0.0.1 at 2017-10-17 06:59:26 +0000 
Processing by SessionsController#new as HTML 
    Rendering sessions/new.html.erb within layouts/empty 
    Rendered sessions/new.html.erb within layouts/empty (1.1ms) 
Completed 200 OK in 6ms (Views: 4.9ms | ActiveRecord: 0.0ms) 
    (0.4ms) ROLLBACK 

は、だから私はテストログ( docker-compose run web tail -f log/test.log

そして、何私が見つけたことを私に不可解さをつかれました。しかし、何らかの理由でCapybaraが何らかの理由でルートURLを取得しようとしましたが、電子メール/パスワードのパラメータを渡してしまいました。私のルートURLはLocationsController#インデックスにマッピングされています。メッセージPlease log in to see this pageで/ loginにリダイレクトされました。そのボタンが実際に行うことは、SessionsController#createにPOSTを送信することです。あなたはログを見れば、あなたが手動でそれを行うときに、それが起こるまさにだ:

web_1 | Started POST "/sessions" for 172.18.0.1 at 2017-10-17 07:02:19+0000 
web_1 | Processing by SessionsController#create as HTML 

あなたはそれはあなたがボタンをクリックしたときに完全に異なる要求を実行し、ボタンを押したときに、私はカピバラに理由を動作することはできません手動で

大変助かりました!

答えて

1

最初にいくつかの説明があります。

  1. あなたはそれがすでに設定されていますので、あなたがRSpec.featureを使用している場合:type => :featureを指定する必要はありませんRSpec.feature:type => :feature
  2. の使用によって証明されるように(あなたが機能の仕様を書いている、要求スペックを書いていない。

今のあなたの問題へのform_tag<form>要素を作成しますので、あなたはあなたのビューのコードでフォームを入れ子にしていると、あなたはその中に直接、別の<form>の要素を持っている(注:これは、投稿することは常に良いでしょう実際のHTMLではなく、実際のHTMLを使用することができます)。それが、無効なHTML(ネストされたフォーム)が実際のブラウザと同じように振る舞わないように、メタデータのrack-testドライバを使用しているように見えます。 。私はあなたが実際のブラウザでそれを使用するとき、内側のフォーム要素は無視され、外側のフォーム要素は "投稿"に等しいメソッド属性を持ち、投稿されると推測します。 rack-testを使用している場合は、おそらくmethod属性を持たない内部フォーム要素を提出しており、デフォルトで「get」になっています。関係のない<form class="m-t" role="form" action="/">フォーム要素を削除してください。

+0

Urghは、そのネストされたフォームを完全に欠いていました。今明らかになったので、あなたはそれを指摘しています!ありがとうございます、また、フィーチャーとリクエストの仕様についてのあなたの点を指摘しました。 –

関連する問題