Rails のブラウザテストを Playwright で動かすようにしたらデバッグが簡単になって捗った - Qiita
Rails, RSpec でブラウザテストというと System Spec, Feature Spec などが挙げられます。バックエンド、フロンテエンド両方を End-to-End でテストするには便利ですが、複雑さ故に、たまに落ちるテストになってしまったり、落ちたときのデバッグが大変という難しさがあります。 Qiita でも主要な機能 (エディタ、記事ページなど) をテストするのに使っているのですが、CI で時折よくわからない理由で落ち、 更に何故落ちたかの再現や調査が難しい というのが結構つらいポイントでした 今回 Qiita で RSpec で利用するブラウザ自動化ツールを Selenium から Playwright を使うように置き換えたら、かなりデバッグが行いやすくなりました 移行自体も Cabybara 用の Driver を使うことで、大きく書き換えることなく移行することが
local のファイルを remote のブラウザで attach_file させるには - Qiita
ブラウザがローカルで動いている分には問題ない。 ブラウザがリモートで動いている場合に失敗する。なぜならリモートマシンに /home/gongo/fixtures/hoge.csv が 存在しないから 対応策としては、リモートマシンにも /home/gongo/fixtures/hoge.csv を配置しておけばいい。しかし…… 並列化のためリモート環境を大量に準備したい → 配置めんどい もしリモート環境が Windows だったら → いちいちリモート環境に併せてパスの記述を変えたくない(C:\Users\gongo\fixtures/hoge.csv みたいに) 実は /path/to 形式でもよしなにしてくれるんですかね…… 対策 Selenium::WebDriver::Driver#file_detector を使います。 Capybara.register_driver :re
Capybaraを使って、Rails+JavaScriptの非同期な統合テストを書く | POSTD
上からも分かるように、ページの読み込みが完了する前に、テストでリンク探しを始めたのにも関わらず、Capybaraは優雅にインタラクションを処理しています。 しかし、Capybaraがこれらの非同期の問題を処理してくれるにもかかわらず、成功したり失敗したりする一貫性のないテストにいとも簡単に陥ってしまうのはなぜなのでしょう。 競合状態の数を最小限に抑えて、Capybara APIを正しく使用するには、いくつかのコツがあります。 最初に適合するエレメントを見つける 悪い例 first(".active").click まだページに.active要素がない場合、firstはnilを返し、クリックは失敗します。 良い例 # 完全に一致するものが欲しい場合 find(".active").click # ただ単に最初の要素がほしいだけの場合 find(".active", match: :first
poltergeistからheadless chromeへ移行する時に気をつけること - メドピア開発者ブログ
こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。最近は子育てに忙しくしています 👶 先日、メドピアで利用しているcapybaraのjavascript driverをpoltergeistからheadless chrome(selenium-webdriver)に移行しました。driverを変更するにあたって既存のテストコードをいくつか修正する必要があったので、そこで得た学びを共有したいと思います。 なぜ移行したのか ここ数年、Railsでエンドツーエンドのテストを書くときにはpoltergeistを使う、というのがデファクトスタンダードだったはずです。それ以前はみんなcapybara-webkitを使っていましたが、poltergeistはバックエンドにPhantomJSを使っており、Qtに依存しているcapybara-webkitと比べてビルドが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Can I automate Chrome request blocking using Selenium-webdriver for Ruby? - Stack Overflow
