Rails アプリケーションの不安定なテストを撲滅したい 〜system spec のデバッグ方法とテストを不安定にさせる要因〜
Rails アプリケーションの開発において、自分の変更に関係のないテストのせいで CI がコケるとストレスですよね？真っ先に直したくなりますよね？不安定なテストを直すのは大変な労力が要ると思ってませんか？実は、たいていのケースは簡単に再現確認ができるし、不安定になる要因もだいたい決まっているし、ログやスクリーンショットを見れば原因も簡単に特定できるんです！ そんなわけで、日頃不安定なテストを潰している身として知見みたいなものをまとめてみました。 今回利用した環境は次のとおりです。 rails 6.0.0 capybara 3.29.0 selenium-webdriver 3.142.4 rspec-rails 3.8.2 Google Chrome 77.0.3865.75 (headless で使用) ChromeDriver 77.0.3865.40 (f484704e052e0b5
Rails: システムテストをRSpecで実行する（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Rails system tests with RSpec 原文公開日: 2017/12/28 著者: Mateusz Dominiak @jnchitoさんの以下の記事も合わせてどうぞ。 rspec-rails 3.7の新機能！System Specを使ってみた Rails 5.1のSystemTestCaseを試してみた 2018/01/25: 初版公開 2023/10/12: 更新 RSpec 3.7登場前のfeature spec は、実物（またはヘッドレス）のブラウザ環境でJavaScriptの絡むアプリのやり取りをフルスタックでテストする手段でした。最近リリースされたRSpec 3.7（訳注: 現在はRSpec 4.0です）では、Railsのシステムテストを元にしたsystem specが追加されました。Rails 5
「Randomly Failing Specs」という内容でLTしました #railsdm - アジャイルSEの憂鬱
資料は Slide Share で公開しています。 Randomly Failing Specs from sinsoku listy www.slideshare.net 話したかったこと 時間切れで全く話せていませんでしたが、本当は「 sleep 使わずに直しましょう」って事が伝えたかった。 資料の作り方や発表内容で完全に失敗してる。 このブログ読んだ方は是非スライドの図を見て、 Capybara のお気持ちを感じ取って欲しい。 他のLT登壇者はだいたい最後の方まで話せていて、流石だなーと思いながら聞いていました。 同人誌 電子版を BOOTH で公開してみました。*1 booth.pm 紙版を購入頂いた方には無料で電子版をお渡ししたいと思っていたので、パスワード付zipを使って用意しました。 パスワードを生成するのが面倒なのですが、他に良い方法が思い浮かびませんでした。申し訳ない。
E2Eテストがたまに落ちるときのよくあるパターン - Qiita
Capybara を使って PhantomJS や Selenium などブラウザを介した E2E テストをするときに遭遇する、たまに落ちるテストのパターンをまとめていく。 ケース1: 押し損ね 落ちたときの状況 ボタンやリンクのクリックに失敗してそうに見える。 原因 click_on などはクリックするときに対象の要素を見つけ、 x 座標と y 座標を取得した上でその座標をクリックする。 対象の要素を見つけたときとクリックする瞬間の座標が異なるため、クリックはしているが目標の要素をクリックはできていない。 ずれる理由の多くは画像などの読み込みに伴う座標のずれ。 アニメーションもずれ得るが自分で把握して適宜待つようにしているパターンが多いのでだいたいの場合問題にはなっていない。 対策 読み込みタイミングによらず座標が固定されるような CSS を書くのが理想的。 回線によってはユーザもボタン
RSpec/Capybaraのテストコードを画面操作から出力するChrome拡張をつくった - memo_md
ほぼ表題の通りの内容で、Chrome拡張を作ってみた。 完成度としてはまだまだだけど、とりあえずざっくり触れる程度にはなったので公開した。 github.com chrome.google.com アイコン画像は、カピバラの写真を適当になぞって作った。 なんでこんなものを？ Capybaraのテストコードを書くのが面倒だなって感じることが多かったのが1つの理由。 TDD的に、先にテストコードを書いていけるのが理想だな〜とは思うものの、Webアプリケーションの開発をしていると、現実には一度は画面から一通り確認して、その後にfeature specを書く流れが多いように感じる。 そしてCapybaraでfeature specを書こうと思うと、 「これはテキストじゃなくてIDで選択しないとダメか〜」 「あ〜、これはfindしてからsetしないといけないのか〜」 という感じで、スムーズに書けない
RSpec の feature spec でヘッドレス Chrome を使う - Speee DEVELOPER BLOG
Speee エンジニア組織推進室の服部 (yhatt) です。 みなさん E2E テストされていますでしょうか。弊社の Ruby on Rails プロダクトにおいては、RSpec、Capybara、 Poltergeist を組み合わせ、 feature spec で E2E テストを行う構成が一般的でした。 そんな中、Chrome 59 に ヘッドレスモード (--headless) が搭載 されたことで、テストや CI 環境において、最新の Chrome 環境による E2E テストを実施できるようになりました。それに合わせて、PhantomJS のコアメンテナーがメンテナーを降りる ことを発表し、PhantomJS のアップデートや、継続的サポートは期待できない状況となっています。 ヘッドレス Chrome ことはじめ | Web | Google Developers [A
Webページを監視して表示崩れが起きていないか検出できるE2Eテストを実装しました | Recruit Tech Blog
お世話になります、フロントエンド担当をしている小原正大です。Webページの表示を監視して差異があった場合、どのページで表示の変化が起きているかを知ることが出来るプログラムを実装したのでそのことについて書こうと思います。 何につかったの？ 僕がフロントエンドを担当しているサービス『料理サプリ』で大規模なフロントエンドコードのリファクタリング行う際に表示テストを自動化するために作成しました。『料理サプリ』はPC・スマホ合わせて大体350-400ページの表示パターンが存在する比較的規模の大きいサイトです。全ページに影響を与えるような作業は大規模な回収となり、今回のリファクタリングでは表示テストの計画などの段取りが必要でした。従来の人手によるQAでは細かいバグを見過ごしたり時間がかかり効率が悪いので、可能な限り自動化しようと考え実装しました。 実装の概要 この監視のシステムは以下の２つ実装を組合わ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The One True Guide to database transactions with Capybara - Ian's Tech Notes