不安定テストを生み出すCapybaraを調教する銀座Rails#22での発表資料です。 https://ginza-rails.connpass.com/event/176491/
Rubyで動的解析して、関係があるテストも実行する｜kiha
この記事は note株式会社 Advent Calendar 2024 の17日目の記事です。 あるRubyクラスを変更したがそのプログラムのテストケースの実行結果の確認だけでは不十分なことがよくある。例えば、CreateUserService -> Userのようなクラスの依存関係があったとする。プログラマはUserクラスに対して変更を加えたので、Userクラスに対するテストケースを実行すれば確認としては十分であると考えた。しかし、実際にはUserクラス単体ではCreateUserServiceからの実際の利用のされ方は確認できないし、保証もできないので（特にRubyプログラムであることも踏まえて）、うっかりUserクラスの振る舞いが変わってしまったことで、連鎖的にCreateUserServiceの振る舞いに影響してしまうということがよくある。 この問題には、以下のような解決策が考えら
フレーキーテストの解消に役立つ便利な gem capybara-lockstep - Qiita
この記事はソニックガーデン プログラマ アドベントカレンダーの16日目の記事です。 はじめに Rails のシステムテストって便利ですよね。実際にユーザーが使うシチュエーションをブラウザからRails、データベースまで包括的にテストできる。素晴らしい仕組みだと思ってます。 そんなシステムテストですが、アプリが大きく成長してきてユーザー体験を重視したリッチなUIやUXが充実しだしたりしたときに、こんな状態に遭遇しだしたりします。 なぜか、CIで自動テストが通らない 再実行したらうまくいく ローカルでは、テストが通る（テストの失敗が再現しない） 実際に体験した人ならわかると思うんですが、CIと同じ状況をなかなか再現できなくって厄介ですよね。 原因のわからない不可解な事情にプログラマとしては、どうにかしたいなと思いつつ、泣く泣く再実行してテストが通るまでリトライボタンを押したり、ローカルではテス
Rails のブラウザテストを Playwright で動かすようにしたらデバッグが簡単になって捗った - Qiita
Rails, RSpec でブラウザテストというと System Spec, Feature Spec などが挙げられます。バックエンド、フロンテエンド両方を End-to-End でテストするには便利ですが、複雑さ故に、たまに落ちるテストになってしまったり、落ちたときのデバッグが大変という難しさがあります。 Qiita でも主要な機能 (エディタ、記事ページなど) をテストするのに使っているのですが、CI で時折よくわからない理由で落ち、 更に何故落ちたかの再現や調査が難しい というのが結構つらいポイントでした 今回 Qiita で RSpec で利用するブラウザ自動化ツールを Selenium から Playwright を使うように置き換えたら、かなりデバッグが行いやすくなりました 移行自体も Cabybara 用の Driver を使うことで、大きく書き換えることなく移行することが
RSpec: Behaviour Driven Development for Ruby
Take very small stepsDon’t rush ahead with more code. Instead, add another example and let it guide you to what you have to do next. And don’t forget to take time to refactor your code before it gets messy. You should keep your code clean at every step of the way. View Documentation The BookEffective Testing with RSpec 3: Build Ruby Apps with ConfidenceThis definitive guide from RSpec’s lead devel
System tests have failed
When we introduced a default setup for system tests in Rails 5.1 back in 2016, I had high hopes. In theory, system tests, which drive a headless browser through your actual interface, offer greater confidence that the entire machine is working as it ought. And because it runs in a black-box fashion, it should be more resilient to implementation changes. But I'm sad to report that I have not found
Railsプロジェクトで発生するflaky testの傾向と対策｜グロービス・デジタル・プラットフォーム
はじめにはじめまして。この一年ほど学び放題のDevExpチームでバックエンド開発のお手伝いをしてるmasa_iwasakiです。 今回の記事では、学び放題のバックエンドとして使われているRailsアプリケーションで実際に発生していたflaky testの事例を中心に、一般的なRailsアプリケーションで発生しがちなケースをまとめました。 個人的に、flaky testの発生パターンは割と定番化している印象を持っています。たとえば、以下の記事に記載されている内容と本記事の内容は共通するものが多いです。 Ruby: テストを不安定にする5つの残念な書き方（翻訳）｜TechRacho by BPS株式会社 しかし、同じ原因で発生したflaky testであっても、コードベースが異なれば発生の仕方は変わりますし、なにより原因の調査にかかる手間は大きく異なります。本記事がflaky testに遭遇し
E2Eテストでバリデーションを調整してタイムアウトを抑制する - おもしろwebサービス開発日記チラシの裏
関連: system specでNet::ReadTimeoutになったら - おもしろwebサービス開発日記チラシの裏 やっぱりタイムアウトの時間を伸ばすのではなく、テスト側でバリデーションの条件を緩和してあげたほうがトータルのテスト実行時間が短くなっていいんじゃないか、と思って次のようにした (設定はpalkan/anyway_config: Configuration library for Ruby gems and applicationsを使っています) class DailyReport < ApplicationRecord validates :body, presence: true, length: { maximum: -> { ValidationConfig.daily_report[:body][:maximum] } } end around do |exa
circleciに入門したので設定ファイルを解説する。 - Qiita
初めに 今回は備忘録を兼ねて、circleciの基礎について解説します！ 私と同じようなビギナーの方に向けてできるだけ分かりやすく解説しますので良ければご覧ください。 なお、今回使用するCircleCIのconfig.ymlはリンク先の記事を使用させていただいております。 【circleCI】Railsアプリでgithubと連携してrubocopとrspecテストを走らせる 使用する設定ファイル 今回はcircleciの設定ファイルについての解説ですので、導入方法などについては割愛します。 # Ruby CircleCI 2.0 configuration file # # Check https://circleci.com/docs/2.0/language-ruby/ for more details # version: 2 jobs: build: docker: # speci
3年の運用で編み出した CircleCI 超設計大全 - Qiita
個人でも業務でもすごくお世話になっている CircleCI について説明したいと思います。 設定する際の Tips など個人的な観点を元に紹介していきます！ CircleCI の構造をざっくりと理解する CircleCI で設定する .circleci/config.yml ファイルの中身の構造について理解していきます。 config.yml は大きく分けて、 version, orbs, executors, commands, jobs, workflows の6つのキーワードに分かれています。 この6つのキーワードを理解することで CircleCI がよくわからない方もざっくりと理解することができます。 version キーワードを除くその他のキーワードを見てもらうとわかりますが、基本的に ****s になっているので複数指定することができます。 では順番にそれぞれのキーワードについ
flashメッセージが時々表示されないflakyテストを改善した話 - おもしろwebサービス開発日記チラシの裏
Railsで cookie sessionを使っている 非同期でAPIをよく叩いている という条件下で、例えば日報を投稿したあとに"投稿しました！"というflashメッセージを表示しているはずなのになぜか"投稿しました！"が表示されないという現象が時々起こっていました。 これは次のようなことが原因だと推測しています。 非同期API(例: 日報のプレビューを表示する)が実行される 日報投稿ボタンを押す 投稿が成功して日報詳細ページへのリダイレクト用のレスポンスが返される SetCookiesでflashメッセージを含んだcookie sessionが返される 非同期APIのレスポンスが返る SetCookiesでflashメッセージを含まないcookie sessionが返される 日報詳細ページへのリクエストが実行される このとき送信するCookieにはflashメッセージが含まれていないの
MysqlRewinder という gem を作った | BLOG - DeNA Engineering
gem の概要 database_rewinder という gem があります。 これを使うとテストケースを実行するたびに DB の中身が初期化されて、しかも超速いというすごい gem です。 弊社でもヘビーユースさせていただいていたのですが、あるプロダクトの自動テストにおいて適切にデータが初期化されないケースがあり、 Flaky test の原因となっていました。 今回ご紹介する mysql_rewinder は、この問題を解決するために database_rewinder の代替を目指して開発した gem です。 使用例 Ruby on Rails / RSpec と組み合わせる場合、以下のように利用します。 RSpec.configure do |config| # MysqlRewinder の初期設定 config.before(:suite) do db_configs = A
Rails のブラウザテストを Playwright で動かすようにしたらデバッグが簡単になって捗った
Omotesando.rb #91 (https://omotesandorb.connpass.com/event/299381/) で発表した資料です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rails Fixtures再考
GitHub - rubocop/rspec-style-guide: Best practices for writing your specs!
Replacing system tests with unit tests | Everyday Rails
RSpec Mocks ドキュメント拾い読み - Qiita
The Resurrection of the Fast Parallel Test Runner
Method: RSpec::Mocks::ArgumentMatchers#array_including — Documentation for rspec/rspec-mocks (main)
GitHub - asonas/rspec-daemon
