当文書はRails + Rspec + Capybara環境を想定しています。 他のアプリ/テストフレームワークを利用したい場合は公式のREADMEを参照願います。 概要 Capybara = UIテストのためのrubyフレームワーク オープンソース / MITライセンス ページの表示、フォームの入力、ボタンのクリック等のUI操作をテストコード上で実行できる 複数のテストフレームワークから利用できる MiniTest, RSpec, Cucumberなど 複数の ドライバ (テスト環境, ヘッドレスブラウザ)を選択して利用できる Rack::Test, Selenium, Webkitなど 導入 インストール gemをインストールする。 Railsの場合、バージョンによってはデフォルトでGemfileに追加されている。
We have a race condition between click_link and reload_page. Sometimes the AJAX call will go through before Capybara reloads the page, and sometimes it won’t. This kind of nondeterministic test can be very difficult to debug, so I added a little helper. Capybara’s Little Helper Here’s the helper, via Coderwall: # spec/support/wait_for_ajax.rb module WaitForAjax def wait_for_ajax Timeout.timeout(Ca
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第4回です。 今回はCapybaraを使ったフィーチャスペックについて説明します。 ただし、今までの記事とは異なり、フィーチャスペックのイロハよりも「Capybaraの使い方」に重点を置きます。 なぜなら、僕個人の経験からいって、フィーチャスペックで困るのは「このブラウザの操作って、どうやってコードで表現するの？？」というケースが大半だからです。 それ以外は第1回～第3回の内容をそのまま応用できるので、特に「フィーチャスペックだから困る」ということはないと思います。 今回は説明する主な項目は以下の通りです。 フィーチャスペックの基本 ページの移動や画面のクリック、フォームの操作など 画面やフォームの検証 画面の操作や検証の応用テクニック その他
CucumberとCapybaraとPoltergeistを使ってテストをしていたときに、 別タブで開くリンク（target="_blank"となっているリンク)のテストで引っかかった。 別タブで開くリンクのクリック target="_blank"となっているリンク（ボタン）を click_buttonやclick_link、click_onを使ってクリックしたところ TimeoutErrorが発生した。 teampoltergeist/poltergeistを読んでみると If you can't figure out what's going on and just want to work around the problem so you can get on with life, consider using a DOM click event. For example, if
Minitestでテストが失敗したかどうかで処理をわけるSat, 22 Jul 2017 02:46:17 GMTテスト Ruby Selenium Capybara Minitest かなり久しぶりにSelenium + Capybara + Minitestの組み合わせでE2Eテストをやってるのですが、テストに成功した場合と失敗した場合とで処理を分けたかったのでやってみました。 環境 Minitest 5.10.2 Ruby 2.4.1 やり方 Seleniumを使用してこのサイトを開いて「酔っ払いITエンジニア」の文字が含まれていれば成功とします。存在しない文字を含んでいれば失敗とします。今回はサンプルなので成功するケースtest_blog_oneと失敗するケースtest_blog_twoを作成しました。 なお、requireで前書いた記事で作ったtest_helper.rbをロード
注意 この訳はだいぶ古い(2011年7月時のREADME)です。最新版の訳をgithub上に載せたのでこちらをご覧ください。 はじめに Rails のエンドツーエンドテスト用のデファクトスタンダードプラグイン Capybara の README 意訳です。いつもと比べて直訳成分多めです。 テスト関連はどうにも日本語の情報が少なくて、覚えるのが大変ですね＞＜ 概要 Capybara は Rack アプリ(Rails, Sinatra, Merb等)の統合テストを簡単にするのが目的です。Capybara は現実のユーザがウェブアプリとやりとりするのをシミュレートします。テスト用のドライバを選択できます。デフォルトでは Rack::Test と Selenium ドライバをビルトインでサポートしています。HtmlUnit, env.js は外部の gem としてサポートしています。 完全なリファ
ほぼ表題の通りの内容で、Chrome拡張を作ってみた。 完成度としてはまだまだだけど、とりあえずざっくり触れる程度にはなったので公開した。 github.com chrome.google.com アイコン画像は、カピバラの写真を適当になぞって作った。 なんでこんなものを？ Capybaraのテストコードを書くのが面倒だなって感じることが多かったのが1つの理由。 TDD的に、先にテストコードを書いていけるのが理想だな〜とは思うものの、Webアプリケーションの開発をしていると、現実には一度は画面から一通り確認して、その後にfeature specを書く流れが多いように感じる。 そしてCapybaraでfeature specを書こうと思うと、 「これはテキストじゃなくてIDで選択しないとダメか〜」 「あ〜、これはfindしてからsetしないといけないのか〜」 という感じで、スムーズに書けない
上からも分かるように、ページの読み込みが完了する前に、テストでリンク探しを始めたのにも関わらず、Capybaraは優雅にインタラクションを処理しています。 しかし、Capybaraがこれらの非同期の問題を処理してくれるにもかかわらず、成功したり失敗したりする一貫性のないテストにいとも簡単に陥ってしまうのはなぜなのでしょう。 競合状態の数を最小限に抑えて、Capybara APIを正しく使用するには、いくつかのコツがあります。 最初に適合するエレメントを見つける 悪い例 first(".active").click まだページに.active要素がない場合、firstはnilを返し、クリックは失敗します。 良い例 # 完全に一致するものが欲しい場合 find(".active").click # ただ単に最初の要素がほしいだけの場合 find(".active", match: :first
自分がCapybaraで一番ハマったのは、画面の初期化や、Ajaxやアニメーションなどの遅延を待たずに、どんどんclickなどを行おうとして意図しない結果になってしまうこと。 ブラウザから自分で試してみてもうまく行くので、自動テストをうまく行かせるためだけのデバッグ作業となり、作業のための作業、これは無駄以外のなんでもない。腹立たしい。 だから、情報共有。 findで要素が準備OKになるまで待たせる 本家の でも書かれているが、Capybaraにはこういう非同期JavaScriptの問題への対処として、findや、have_content実行時にまだ要素が見つからない場合は、設定した時間(初期値2秒)待ってからリトライをしてくれる。 この機能を使って、clickする、have_xxx で検証するなどの前に、findでちゃんと存在するまでcapybaraに待たせる事が重要。 基本的に非表示要
前回の記事、 Dockerを使ってHeadless Chromeを動かしてみるでDockerからHeadless Chromeを使う環境が出来たので、これをベースにCapybaraからHeadless Chromeを使う環境を構築してみます。 Docker Imageの構築 前回からの変更点としては、chromium-chromedriverの追加とRuby関連のライブラリの追加です。nokogiri等も入れてbunlde install時に 困らないようにしておきます。 FROM alpine:edge RUN apk add --update \ udev \ ttf-freefont \ chromium \ chromium-chromedriver RUN mkdir /noto ADD https://noto-website.storage.googleapis.com/pk
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
