Capybara 3.0.0にてCapybara::Element::Node#textなどの戻り値が変化する仕様変更があった

Capybara 3.0.0(厳密には3.0.0.rc2)にて、

• Visibile text whitespace is no longer fully normalized in favor of being more in line with the WebDriver spec for visible text

という仕様変更が行われた結果、

element = page.first('.some-element')
expect(element).to have_content("Foo\nBar")

のように Capybara::Element::Node のコンテンツに対して「改行」や「連続する空白文字」を期待値としているテストが失敗するようになりました(実際の値として返される文字列が Foo Bar のようになるため)。

これはどうやら、「ブラウザ上での表示に近い文字列を返す」ようにする意図の変更のようです。

• Change #text to be closer to what a browser displays by twalpole · Pull Request #1982 · teamcapybara/capybara

従来どおりにテストを成功させるための対応としては、

element = page.first('.some-element')
expect(element.native.text).to have_content("Foo\nBar")

のようにネイティブなオブジェクト経由で文字列を取得するようにすればよさそうです。

rspec 3.7でOmniAuthのテストモードが失敗するようになった場合の対策。

rspec (rspec-rails) を3.7.xにアップデートしてから、Integration Testing · omniauth/omniauth Wikiにあるような OmniAuth.config.test_mode を使ったFeature specが失敗するようになってしまった場合は、Pumaがclusters modeで動作するように設定されていないか見直すこと。

具体的には、config/puma.rb がHerokuの推奨する以下のような設定になっていると、

workers Integer(ENV['WEB_CONCURRENCY'] || 2)

テスト時にOmniAuthのモックがうまく設定されない状態でテストが実行されてしまうようになる。

これを、

if  ENV.fetch('RAILS_ENV') { 'development' } == 'test'
  workers 0
else
  workers Integer(ENV['WEB_CONCURRENCY'] || 2)
end

のようにしてclusters modeでは動作しないようにした状態でテストを実行すると、おそらく従来通りの結果が得られる。

他にも VCR.use_cassette '...' { ... } のようにVCRで囲んだ部分でもリクエストをフックしてモックデータを返すような動作をしなくなるなど、clusters modeにしていることによってハマることがある。

• mock_auth doesn't redirect to success url with rspec 3.7.0 · Issue #918 · omniauth/omniauth
• capybara - How can I use VCR with Rails 5.1 system tests? - Stack Overflow
• Use the default Capybara registered puma server configuration by twalpole · Pull Request #30638 · rails/rails

PhantomJSからChromeDriverに移行した場合にテストでダイアログのボタンをどのように押すか

Poltergeist + PhantomJSという組み合わせでRailsアプリのFeature specを書いている場合、JavaScriptのalertやconfirmでダイアログが開かれた時には常にOKボタンが押されるようになるため、クリックすると確認のダイアログが開くようなボタンを押すテストは以下のようなコードで実行することができる。

find("#button-with-confirm").click

これを、ChromeDriveとselenium-driverを使ったFeature specに移行した場合、以下のようにCapybaraのaccept_alertを利用して明示的にダイアログのボタンを押すようなコードにする必要がある。

accept_alert do
  find("#button-with-confirm").click
end

Rails 5.1の新しいform_withヘルパーはINPUT要素にid属性を設定しない

Rails 5.1で新たに導入された form_with ヘルパーは、これまでの form_for ヘルパーと違って、そのフォームオブジェクトを利用して生成されるDOM要素にid属性やclass属性をできるだけ付けないように設計されているようだ。

• form_with is not assigning id's to inputs · Issue #29450 · rails/rails
• Provide form_with as a new alternative to form_for/form_tag · Issue #25197 · rails/rails

したがって、従来の form_for ヘルパーによって以下のようなHTMLが生成されていた場合に、

<label for="title_genre">作品ジャンル</label>
<input type="text" id="title_genre" value="...">

Capybara を使った feature spec 内で、以下のようにLABEL要素とINPUT要素のfor/id属性値による紐付けを利用して、

fill_in '作品ジャンル', with: 'ホラー'

のように指定していた箇所の実行が Capybara::ElementNotFound: Unable to find field "作品ジャンル" で失敗するようになる。

これを回避するためには、新しい form_with ヘルパーのフォームオブジェクトを利用してDOM要素を生成する際に、以下のように明示的にid属性値を指定する必要がある。

<%= form_with(...) do |form| %>
  <%= form.label(:genre) %>
  <%= form.text_field(:genre, id: :title_genre) %>
<% end %>

このあたりの挙動についてはAPIリファレンスのform_withの項目で詳しく解説されている。

また、以下のように label ヘルパーをブロックを渡す形で利用している場合には、生成されるLABEL要素にfor属性が設定される一方でブロック内のINPUT要素などにはid属性値が自動設定されないため、意図した動作（「確認しました」の部分をクリックするとチェックボックスが切り替わる）にならない場合がある。

<%= form.label(:confirmation) do %>
  <%= form.check_box(:confirmation) %> 確認しました
<%= end %>

これを解消するには、今のところ for 属性値を設定しないことを label ヘルパーで明示する必要があるようだ。

<%= form.label(:confirmation, for: nil) do %>
  <%= form.check_box(:confirmation) %> 確認しました
<%= end %>

CircleCI上でのRails 5.0.0.rc1 + factory_girl_railsのビルドがPG::UndefinedTableで失敗する件

以下のような構成のRailsアプリをCircleCIでビルドする際、

• Rails 5.0.0.rc1
• factory_girl_rails 4.7.0

rake db:create db:schema:loadやrake db:create db:structure:loadのフェーズで以下のような例外が発生してビルドが失敗するようになった。

ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR:  relation "posts" does not exist
LINE 8:                WHERE a.attrelid = '"posts"'::regclass
                                          ^
:               SELECT a.attname, format_type(a.atttypid, a.atttypmod),
                     pg_get_expr(d.adbin, d.adrelid), a.attnotnull, a.atttypid, a.atttypmod,
             (SELECT c.collname FROM pg_collation c, pg_type t
               WHERE c.oid = a.attcollation AND t.oid = a.atttypid AND a.attcollation <> t.typcollation),
                     col_description(a.attrelid, a.attnum) AS comment
                FROM pg_attribute a LEFT JOIN pg_attrdef d
                  ON a.attrelid = d.adrelid AND a.attnum = d.adnum
               WHERE a.attrelid = '"posts"'::regclass
                 AND a.attnum > 0 AND NOT a.attisdropped
               ORDER BY a.attnum    

スタックトレースやrake db:schema:load fails - CircleCIを見た結果、以下のような流れになっていることがわかった。

• Railsのロード過程でfactory_girl_rails/railtie.rbが読み込まれる
• FactoryGirl.find_definitionsが呼び出される
• spec/factories/*.rbが読み込まれる
• モデルクラスがロードされる
• モデルクラスに対応するテーブルがまだ存在しないため例外が発生

Rails 5.0がリリースされるまでの過程で解消するのかもしれないが、ひとまずGemfileではfactory_girl_railsをrequireしないようにして、

group :test do
  ...
  gem 'factory_girl_rails', '4.7.0', require: false
  ...
end

そのかわりにspec/spec_helper.rbで明示的にrequireする形にして問題を回避することにした。

#
# factory_girl_rails
#
# To prevent PG::UndefinedTable excetion during `rake db:structure:load` on
# CircleCI build, we don't require the gem in Gemfile.
# Because of this, we need to require it explicitly here.
#
# See: https://circleci.com/docs/ruby-exception-during-schema-load/
#
require "factory_girl_rails"