不安定テストを生み出すCapybaraを調教する銀座Rails#22での発表資料です。 https://ginza-rails.connpass.com/event/176491/
Rails E2Eテストで poltergeist から Headless Chrome へと乗り換える
目次 対応 Pull RequestInstall selenium-webdriverChange Capybara.javascript_driverInstall chromedriver On MacOSOn CircleCIOn TravisCI参考リンクRailsのCapybaraを使ったE2Eテスト(feature spec)をこの度、poltergeistからHeadless Chromeに乗り換えてみたのでそのときのメモ。 対応 Pull Request今回対応したPull Requestはこちら。 Use headless Chrome instead of PhantomJS(poltergeist) by toshimaru · Pull Request #211 · toshimaru/RailsTwitterClone · GitHub 思ったよりも差分はコンパ
poltergeistからheadless chromeへ移行する時に気をつけること - メドピア開発者ブログ
こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。最近は子育てに忙しくしています 👶 先日、メドピアで利用しているcapybaraのjavascript driverをpoltergeistからheadless chrome(selenium-webdriver)に移行しました。driverを変更するにあたって既存のテストコードをいくつか修正する必要があったので、そこで得た学びを共有したいと思います。 なぜ移行したのか ここ数年、Railsでエンドツーエンドのテストを書くときにはpoltergeistを使う、というのがデファクトスタンダードだったはずです。それ以前はみんなcapybara-webkitを使っていましたが、poltergeistはバックエンドにPhantomJSを使っており、Qtに依存しているcapybara-webkitと比べてビルドが
「現在時刻」を外部入力とする設計と、その実装のこと - クックパッド開発者ブログ
こんにちは。技術部 開発基盤グループの諸橋です。 クックパッドでは昨今の多くのWeb企業と同じように、GitHub EnterpriseのPull Requestを使ったコードレビューを広範に実施しています。わたしたちのコードレビューでは、ソースコードの字面にとどまらず、サービスの機能として魅力的かどうかや、保守性を含めた設計が適切かといった議論に発展することも良くあります。 きょうはそんななかで話題に上がった「現在時刻」の扱いかたに関する設計の話を書きます。 背景 サービスを開発・運営している我々には、時間帯によって出し分けたり、特定の期間のみに表示したいコンテンツがたくさんあります。 そのたびにデプロイし直すというのはつらいので(特に24:00に出なくなるコンテンツなど)なんとかしたくなりますが、一方で時限式のコンテンツはその時になるまでちゃんと動いているか確証が取れないので怖いです。
Rails EngineでCapybaraを導入しようとしてハマったこと - Qiita
Rails EngineにCapybaraを導入しようとしてハマったことが二つあるので、備忘録として残しておきたいと思います。 ルーティングを認識させる Railsアプリを普通に書いている場合は気にする必要がないのですが、Rails Engineでfeature specをいきなり動かそうとすると、visit (path)のところで以下のようなエラーが発生します。 1) method_call_situation pages (permit WebUI) render Succsess Failure/Error: visit method_call_situations_path NameError: undefined local variable or method `method_call_situations_path' for #<RSpec::ExampleGroups::M
CircleCI上でCapybara, Poltergeist, PhantomJSを利用したテストがMouseEventFailed失敗す... - Sooey
CircleCI上でCapybara, Poltergeist, PhantomJSを利用したテストがMouseEventFailed失敗する問題を解消した。 以下のような構成のRailsアプリをCircleCI上でビルドすると、Capybara::Poltergeist::MouseEventFailedという例外が発生してテストが失敗するケースがあった。 Rails 4.2.x RSpec 3.4.x Capybara 2.6.2 Poltergeist 1.9.0 PhantomJS 2.1.1 (CircleCIのプロジェクト設定でUbuntu 14.04 (Trusty) containerを利用するように設定しておく必要あり) この時、失敗の原因となっているテストコードは、 click_link '日本語のラベル' のようなもの。 調査のためにCircleCIにSSHで接続し、
Capybaraでテスト中に現在のページをブラウザで開けるgem「launchy」 - アプリなどを開発するブログ
テスト実行中に、「今ってどんな状態なんだっけ？」と知りたいことがあります。 そこで役に立つのがlaunchyというgemです。 https://www.ruby-toolbox.com/projects/launchy 使い方 launchyをインストール Gemfile group :test do gem 'launchy', '2.4.2' end $ bundle install --without production specファイルを記述 describe "Top page" do it "should have 'home page'" do visit '/static_pages/home' # ブラウザで開く save_and_open_page page.should have_content('home page') end うん。便利です。
Capybaraを使って、Rails+JavaScriptの非同期な統合テストを書く | POSTD
上からも分かるように、ページの読み込みが完了する前に、テストでリンク探しを始めたのにも関わらず、Capybaraは優雅にインタラクションを処理しています。 しかし、Capybaraがこれらの非同期の問題を処理してくれるにもかかわらず、成功したり失敗したりする一貫性のないテストにいとも簡単に陥ってしまうのはなぜなのでしょう。 競合状態の数を最小限に抑えて、Capybara APIを正しく使用するには、いくつかのコツがあります。 最初に適合するエレメントを見つける 悪い例 first(".active").click まだページに.active要素がない場合、firstはnilを返し、クリックは失敗します。 良い例 # 完全に一致するものが欲しい場合 find(".active").click # ただ単に最初の要素がほしいだけの場合 find(".active", match: :first
使えるRSpec入門・その4「どんなブラウザ操作も自由自在！逆引きCapybara大辞典」 - Qiita
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第4回です。 今回はCapybaraを使ったフィーチャスペックについて説明します。 ただし、今までの記事とは異なり、フィーチャスペックのイロハよりも「Capybaraの使い方」に重点を置きます。 なぜなら、僕個人の経験からいって、フィーチャスペックで困るのは「このブラウザの操作って、どうやってコードで表現するの？？」というケースが大半だからです。 それ以外は第1回～第3回の内容をそのまま応用できるので、特に「フィーチャスペックだから困る」ということはないと思います。 今回は説明する主な項目は以下の通りです。 フィーチャスペックの基本 ページの移動や画面のクリック、フォームの操作など 画面やフォームの検証 画面の操作や検証の応用テクニック その他
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ちょうどよい Rails E2E テスト/enough-good-rails-e2e-test