「リーダブルなテストコードについて考えよう ～VeriServe Test Automation Talk No.3～」で使用したスライドです。 https://veriserve-event.connpass.com/event/243280/ 登壇動画はこちらで公開されています。 http…
「リーダブルなテストコードについて考えよう ～VeriServe Test Automation Talk No.3～」で使用したスライドです。 https://veriserve-event.connpass.com/event/243280/ 登壇動画はこちらで公開されています。 http…
先日、このブログでもお伝えしましたが、「VeriServe Test Automation Talk No.3」というオンラインイベントで登壇してきました。 veriserve-event.connpass.com 申込者数はなんと1000人を超えていて、大変驚きました。 僕は「リーダブルテストコード」というテーマで発表しました。スライドはこちらです。 Twitterでたくさんシェアされたり、はてなブックマークがたくさん付いたり、こちらもすごい反響でビックリしました。 で、どんな内容だったの？ ひとことで言うなら「テストコードを徹底的にDRYにしようとしちゃダメよ！」というお話です。 このネタは昔からQiitaやTwitterとかでことあるごとに話してきましたが、この勉強会であらためてなぜダメなのか、DRYに書かず、どう書くべきなのか、という話を力説してみました。 優秀なプログラマほど、「
.NET Conf 2025 の興味のあるセッ ションを復習した / dotnet conf 2025 quick recap for backend engineer
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
この記事は 食べログアドベントカレンダー2024 の12日目の記事です🎅🎄 目次 目次 はじめに 自動テスト作成の課題 テストケースを考えることの難しさ テストコードに落とし込む作業の負担 テスト対象のコード例 RSpecでのテストコード例 自動テスト作成の課題がもたらす影響 生成AIと自動テスト 自動テスト作成の効率化を目指して 導入の条件 Difyを活用したチャットボット チャットボットの利用方法 テスト生成の障害 実装コードをそのまま送った場合の問題点 良い自動テスト生成が可能なケース プロンプトの工夫 プロンプトや対話の工夫では解決できないこと 設計の重要性 まとめ ロジックを切り出した対象での有効性 自動テストと設計の相乗効果 最後に はじめに こんにちは。食べログ開発本部 ウェブ開発2部 第1プロダクトチームで主にバックエンド周りの開発を担当しています、エンジニアの高田です
長年の運用で「Gemfileはこう運用すると上手くいった」という知見が蓄積されてきたので、ここに書き出してみておく。 Bundler/OrderedGemsを有効化する RuboCopの Bundler/OrderedGems Copを有効化する。 悪い例: gem 'puma' gem 'jbuilder' 良い例: gem 'jbuilder' gem 'puma' セクションを分けない 基本的に、独自の判断で空行を入れてセクションを分けたりしない。 ここで言うセクションとは「空行で区切られた１つのまとまり」のことである。Bundler/OrderedGems は、このまとまりの中で辞書順であることを要求する。 悪い例: gem 'aws-sdk-rails' gem 'aws-sdk-s3' gem 'graphql' gem 'graphql-batch' 良い例: gem 'aw
はじめに テストコード一般の考え方 壊れにくいテストを書く 実装した通りに動作することではなく、仕様通りに動作することをテストする テストコードはシンプルにわかりやすく書く 失敗の原因がわかりやすくなるように意識する RSpecの書き方 テストケース名をitの引数で明記する letよりもlet!を使う 通常の変数と同じ方針に基づいてlet!を利用する subjectを使わない 不要なcontextでのネストを避ける matcherを適切に使い分ける factoryのデフォルト値に依存しないテストを書く 参考にしたブログ記事等 付録：RuboCop設定 We are hiring! サムネイル画像 はじめに テストコードを書く習慣も、近年ではかなり一般的なものになってきました。 ドワンゴ教育事業のバックエンドチームでも自発的にテストコードを書く文化は根付いており、実際に計測はしていませんが、
CTOの藤村です。つい最近まで STORES ブランドアプリ のチームでRailsを書いていました。 STORES ブランドアプリ のRailsリポジトリではdatabase_cleanerを（strategy = truncationで）使ってテスト中のデータベースをリセットしており、このことがテストコードの品質、速度などで重荷となっていました。 これを、テスト実行時にテストコード自体を書き換えて改善する仕組みを作り、先日無事Transactional Testへの移行が完了しました。ということで気分がとてもよいので、どうやったか共有させてください。 課題 STORES ブランドアプリのRailsのテストコードは速度に課題がありました。 テストデータを片付ける仕組みとして、 Railsエンジニアにはお馴染みのdatabase_cleanerというGemを使っていました。database_
Omotesando.rb #91 (https://omotesandorb.connpass.com/event/299381/) で発表した資料です。
株式会社アンドパッドのアカウント基盤チームでテックリードをしているid:shiba_yu36です。 最近自分のサイドプロジェクトとして、生産性を向上するために、CI実行時間の短縮化を行っていました。その結果、とくに時間のかかっていたCircleCI上のRSpecによるテスト実行時間を、25min -> 12minに改善できました。そこで今回はどのような流れでCIの実行時間を改善していったかについて、具体的に書いてみたいと思います。実行時間改善の勘所について参考になれば幸いです。 改善の流れ: CircleCIでボトルネック調査し、大きいボトルネックを解消する 実行速度改善の前に: Flakyなテストを一斉に直す 速度改善1: bundle installのキャッシュがうまく効いていなかった問題を修正 -> 4minの短縮 速度改善2: developブランチ以外ではカバレッジを取らないよう
Ruby on Rails Advent Calendar 2021の枠が空いていたので、あとから登録しました はじめに 個人的なプロジェクトになりますが、僕が翻訳しているRSpecの入門書「Everyday Rails - RSpecによるRailsテスト入門」を2022年前半にRails 7.0バージョンにアップデートしようと考えています。 そこでこの本の中で使っているサンプルアプリケーションをRails 7.0でゼロから作り直してみました。フロントエンド周りを中心に結構考え方が変わっている部分があったので、「ここでハマった！」とか「こういうポイントを押さえておくといいかも」という点をあれこれ書いてみます。 なお、Rails 7.0版のサンプルアプリケーションはまだ公開できる状態ではないので、公開はもうしばらくお待ちください🙏 今回作成したサンプルアプリケーションはこちらで公開してい
はじめに 僕は折に触れて「RSpecではなるべくsubjectを使わない方がいい」という発言をしています。 Qiitaとか見てるとRSpecのsubjectを愛用している人が多そうな印象なんだけど、僕はほとんど使っていません。「subjectは原則使わない。明らかにメリットがあるときにだけ例外的に使用する」が僕のポリシーです。ほら、RSpecの（元）メンテナさんもそう言ってるし。 https://t.co/Rp5EiIxCVb #Qiita pic.twitter.com/pMlN35ihEG— Junichi Ito (伊藤淳一) (@jnchito) 2019年5月28日 そもそもの話として、RSpecではsubjectは無理に使わない、というのが僕の持論です。なぜなら無理にを使うと、いびつなテストコードができやすいから。基本はsubjectなしで書く。明らかにsubjectが有効なと
STORES 予約 でwebアプリケーションエンジニアをやっております。ykpythemindです。 皆さん、Webアプリケーションのテストを書いていますか。 モック(mock)を使っていますか。 今回は自動テスト上で、偽物だけではなく（要所で）本物を使おうよという話を書きます。 想定読者としては主にRuby on Railsを開発しているバックエンドエンジニアを想定しています。 モックとは 今回のモックの定義は以下にしておきます。 *1 実際の外部サービスや内部サービスの代わりをする偽のサービスを作成することです。 ref: https://circleci.com/ja/blog/how-to-test-software-part-i-mocking-stubbing-and-contract-testing/ Rubyでは外部サービスとの接合部で、 RSpecの allow(xx).
Kaigi on Rails 2021 Day1 14:00-14:30 @YusukeIwaki 「Railsの システムテスト解剖学」の発表資料です
はじめに こんにちは、WEARバックエンド部バックエンドブロックの塩足です。普段は弊社サービスであるWEARのバックエンド開発・保守を担当しています。 WEARのバックエンドでは、これまで自動テスト環境としてCircleCIを使用していましたが、運用保守の改善を目的にGitHub Actionsへ移行しました。 今回は、GitHub Actionsへ移行する際に取り組んだ以下の3点について紹介します。 効率的にテストを分割してテストを並列実行する方法 失敗したテストのみを再実行する仕組みの構築 GitHubのCheck annotationsを活用して、失敗したテスト情報を表示 また、最後に今回行ったテストカバレッジのレポーティングとGitHub Pagesでのホスティングの方法について紹介します。 目次 はじめに 目次 背景 なぜ自動テスト環境をCircleCIからGitHub Acti
Test which reminded me why I don't really like RSpec | Arkency Blog (日本語訳：Rails: RSpecが好きでないことを思い出したテスト（翻訳）｜TechRacho by BPS株式会社) を見ての感想。 元のコードのイマイチなところは 4 つあって、 params を before で書き換えている *1 it "will succeed" の文言 it { is_expected.to be_success } と expect(result.success?).to eq(true) が混ざっている let が不思議な順序で連発されていて事前条件を読み解けない すべて、これによって何をテストしているのかが分かりづらくなっているという問題を引き起こす。 params を before で書き換えている let(:pa
こんにちは。サーバーサイドエンジニアの三村（@t_mimura）です。 主に保険薬局と患者さまを繋ぐ「かかりつけ薬局」化支援アプリ kakariのサーバーサイド開発（Ruby on Rails）を担当しています。 今回はRailsシステムのCI時間をコスト追加なしで半減した話をします。 目次 前提 対象プロジェクト CIの状況 改善結果 改善内容 前提知識: CIのキャッシュ機能 webpack buildのキャッシュを活用 RuboCopのキャッシュを活用 ESLintのキャッシュを活用 Jestのキャッシュを活用 RSpec Jobをテスト特性ごとに分割 CircleCIのリソースクラスと並列数の最適化 採用しなかった・見送った改善候補 HAML-Lint, Fasterer, Brakemanのキャッシュを活用 Stylelintのキャッシュを活用 bootsnapを活用 Jestの
こんにちは、 ydah です。最近はというと、料理への情熱が再燃してきました。一時期は作った料理を全て写真に残していたりとしていたのですが、いつの間にか記録を何も残さなくなっていました。何かしら記録を残すことで、前回よりも味も見た目も良くしようと思えるので、記録を残していくようにしたいと思います。やっていくぞ〜！！ トマトとタコのパスタの近影 はじめに 5/11-13 に長野県松本市 まつもと市民芸術館 で開催された RubyKaigi 2023 の Lightning Talks で、 RuboCop RSpec チーム*1と RuboCop RSpec から、 RuboCop Capybara と RuboCop factory_bot を gem に切り出した話をしました。 rubykaigi.org 当日の発表スライドは以下です。 この記事では RuboCop RSpec を現在使
脅威をエンジニアリングの糧にして：恐怖を乗り越えた先にあったもの / Turn threats into fuel for engineering: what lay beyond overcoming fear
この記事は ANDPAD Advent Calendar 2022 の 7日目の記事です。 qiita.com こんにちは、ydahです。 先日のRubyWorld Conference 2022で燗酒の美味しさに感動していたのですが、ふと気がついたら島根の日本酒がたくさん我が家にいました。 気が付くと何故か我が家にいらっしゃった方々(不思議だ...) そして、また気がつくと枡や徳利、平盃も我が家にいらした(不思議ですね...)のでこれから寒くなるので、燗酒を飲んで温まっていこうと思います。 はじめに 本記事では私が所属しているANDPAD検査チームで取り組んだ以下のことについて紹介いたします。 Request specの改善についてやったこと チームとして改善タスクやリファクタリングを推進するための仕組み作り Request specの改善について 長年、様々な人によって書かれてきていた
表題の通りのことができるgem、CiLoggerが便利ですよという話です。 私達は大量のテストをCI上で実行しています。テスト結果を見れば失敗理由が自明なものもありますが、E2Eテストなどでよく起きる「たまに失敗するテスト」の調査はログやスクリーンショットなど、可能な限りの情報を集めないと根本原因がつかめないことが多いです。 そんなときに、特に考えずRailsデフォルトの設定(config.log_level #=> :debug)のままにしておくと、膨大なログの中から該当するテストに関連する行を探し当てる作業が必要になります。これは事前の準備なしではほぼ不可能です。 事前の準備として簡単に思いつく方法は、テスト前後で「どのテストが開始/終了したか」をログに出力することです。 config.around do |example| Rails.logger.debug("start exam
CIが8分を超えていました。1日に10回pushすれば、待ち時間だけで80分になります。開発のテンポが悪くなるし、プルリクエスト（PR）のフィードバックループも遅れます。 結果から書くと、CI実行時間を8m08s → 3m37sまで短縮できました。55%の削減です。しかも最初のPRではプロダクションコードの変更は一切なく、CI設定とDB設定だけで47%削減しています。 この改善はRailsアプリのCI（GitHub Actions、matrix 5分割、MySQL使用）で行ったもので、似た構成のプロジェクトならそのまま適用できる部分が多いはずです。この記事では、インフラ層の最適化（第1弾）とアプリ層の最適化（第2弾）の2段階に分けて、やったことを順に書いていきます。 改善の全体像 — なぜインフラ層から着手したか 改善前のCI構成 対象はRailsアプリのCIで、GitHub Action
こんにちは、ForShcool事業部の島田です。好きな漫画は「ドラフトキング」です。 スタディプラスではこの度、会社として RSpec に寄付をしました。 rspec.info なぜOSSへ寄付するのか 2020年12月からGitHub Sponsorsで、企業がOSSのスポンサーをすることが可能になりました。 GitHub Sponsorsで、企業がオープンソースプロジェクトや開発者をスポンサーすることができるようになりました。これによって皆さんの企業で利用しているオープンソースプロジェクトを支援しましょう！#GitHubUniverse https://t.co/jQI3fdT5tc— GitHub Japan (@GitHubJapan) 2020年12月9日 この発表の後、日本でも多くの企業がOSSの寄付をしたという記事を目にしました。 時雨堂として GitHub Sponser
FindyでEMをしている栁沢（@nipe0324a）です。 今回は、FindyのとあるRailsのCIのテスト実行時間を10分から5分に高速化した話をご紹介します。 「CIのテスト実行時間が遅い...」 「CIの実行時間を短くしたい!!」 と感じている方はぜひご覧くださいませ。 Findyでは2024年2月現在、1人あたり1日4プルリクを平均で作っています。静的解析や自動テストなどを即時に行うCI環境がないとスピード感のある開発ができなくなるため、CIを高速で回しタスクを完了させる必要があります。機能も増え、テストケースも拡充したことでCIの高速化が求められるようになりました。 また、個人的には、CIは遅くても10分、理想は5分以内で終わるのを1つの目安にしています。これぐらいのスピード感でCIが完了すると、「プルリク作ってレビュー依頼する」、「レビューコメントもらって対応する」といった
この記事はソニックガーデン プログラマ アドベントカレンダーの16日目の記事です。 はじめに Rails のシステムテストって便利ですよね。実際にユーザーが使うシチュエーションをブラウザからRails、データベースまで包括的にテストできる。素晴らしい仕組みだと思ってます。 そんなシステムテストですが、アプリが大きく成長してきてユーザー体験を重視したリッチなUIやUXが充実しだしたりしたときに、こんな状態に遭遇しだしたりします。 なぜか、CIで自動テストが通らない 再実行したらうまくいく ローカルでは、テストが通る（テストの失敗が再現しない） 実際に体験した人ならわかると思うんですが、CIと同じ状況をなかなか再現できなくって厄介ですよね。 原因のわからない不可解な事情にプログラマとしては、どうにかしたいなと思いつつ、泣く泣く再実行してテストが通るまでリトライボタンを押したり、ローカルではテス
RSpecのレビュー大変問題 RSpecって本当に色々な書き方ができますよね。 mockを盛り盛りに書く人、DRYを追求したspecを書く人、itを細かく分ける人 etc... 個人的に、specの書き方は開発チーム内で良しとされているならその書き方で良いと思います。 ただ、新しくチームに入った人や、自分のように普段は違うチームで開発している人が見ると、理解しづらい、レビューしづらい、テストコードを追加、削除しづらい書き方ってあるよな〜と思ったので、まとめてみました。
僕が翻訳しているRSpecの入門書「Everyday Rails - RSpecによるRailsテスト入門」は2014年2月に発売されました。 blog.jnito.com そう、発売からちょうど10年が経ったのです。 いつの間にか10年！僕も全然気付いていませんでした！！ おかげさまで本書は何度となくアップデートを重ねつつ、RSpecの定番の入門書としてたくさんの人に読んでいただいています。 現時点での読者数はのべ6800人以上です。ご購入してくださったみなさん、本当にどうもありがとうございます！ これまでの歴史 どういう流れで本書が翻訳され、現在に至ったのかを簡単にふりかえってみましょう。 2012年5月 原著「Everyday Rails Testing with RSpec」がLeanpubで発売 2013年10月 僕が原著を読み、その感想をブログに投稿 blog.jnito.co
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
Webdrivers::VersionError: Unable to find latest point release version for 115.0.5790. You appear to be using a non-production version of Chrome. Please set `Webdrivers::Chromedriver.required_version = <desired driver version>` to a known chromedriver version: https://chromedriver.storage.googleapis.com/index.html # ./spec/system/tasks_spec.rb:24:in `go_to_project' # ./spec/system/tasks_spec.rb:14:
この記事は note株式会社 Advent Calendar 2024 の17日目の記事です。 あるRubyクラスを変更したがそのプログラムのテストケースの実行結果の確認だけでは不十分なことがよくある。例えば、CreateUserService -> Userのようなクラスの依存関係があったとする。プログラマはUserクラスに対して変更を加えたので、Userクラスに対するテストケースを実行すれば確認としては十分であると考えた。しかし、実際にはUserクラス単体ではCreateUserServiceからの実際の利用のされ方は確認できないし、保証もできないので（特にRubyプログラムであることも踏まえて）、うっかりUserクラスの振る舞いが変わってしまったことで、連鎖的にCreateUserServiceの振る舞いに影響してしまうということがよくある。 この問題には、以下のような解決策が考えら
個人でも業務でもすごくお世話になっている CircleCI について説明したいと思います。 設定する際の Tips など個人的な観点を元に紹介していきます！ CircleCI の構造をざっくりと理解する CircleCI で設定する .circleci/config.yml ファイルの中身の構造について理解していきます。 config.yml は大きく分けて、 version, orbs, executors, commands, jobs, workflows の6つのキーワードに分かれています。 この6つのキーワードを理解することで CircleCI がよくわからない方もざっくりと理解することができます。 version キーワードを除くその他のキーワードを見てもらうとわかりますが、基本的に ****s になっているので複数指定することができます。 では順番にそれぞれのキーワードについ
ある案件で、GitLab CI/CDでRSpecによるテストを自動化しています。 その際に以下の問題がありました。 テスト完了まで30分ほどかかる たまに落ちるテストがある CIでは、テスト成功後に開発環境へ自動デプロイするようになっているため、たまに落ちるテストによりテスト全体を再実行することになり、デプロイ完了まで多くの時間がかかってしまっていました。 改善方針 たまに落ちるテストをいい感じにリトライするCircleCI Workflowsの設定 を参考にさせていただき、失敗したテストのみ実行するretry-testというステージをRSpecを実行するtestステージの後に追加し、only-failuresオプションで失敗したテストのみ再実行できる構成にしました。 ステージを分けることでテストの再実行に失敗しても、retry-testステージのジョブのみをさらに再実行することも可能にな
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Test which reminded me why I don't really like RSpec | Arkency Blog 原文公開日: 2022/11/03 原著者: Szymon Fiedler サイト: Arkency Blog 2023/02/13: 初版公開 2023/02/14: 原文修正を反映（関連ツイート） 最近、別のソフトウェア会社にいる友人がmutantのセットアップについて助けを求めてきました。問題点を発見するためにサンプルテストを共有しながら作業を進めました。Slackチャンネルで以下のスニペットを目にした瞬間、その場で以下のレスを書き込みました。 私: このexampleを見てると自分がRSpecが好きじゃないことを思い出してしまうよ 友人の返事: 好きにレビューしていいから。若手が書いたコ
はじめにはじめまして。この一年ほど学び放題のDevExpチームでバックエンド開発のお手伝いをしてるmasa_iwasakiです。 今回の記事では、学び放題のバックエンドとして使われているRailsアプリケーションで実際に発生していたflaky testの事例を中心に、一般的なRailsアプリケーションで発生しがちなケースをまとめました。 個人的に、flaky testの発生パターンは割と定番化している印象を持っています。たとえば、以下の記事に記載されている内容と本記事の内容は共通するものが多いです。 Ruby: テストを不安定にする5つの残念な書き方（翻訳）｜TechRacho by BPS株式会社 しかし、同じ原因で発生したflaky testであっても、コードベースが異なれば発生の仕方は変わりますし、なにより原因の調査にかかる手間は大きく異なります。本記事がflaky testに遭遇し
こんにちは、アルダグラムの内倉です。 テスト書いていますか？ KANNA では現在、ci で多くの機能のテストをカバーしており、プロダクトの機能・要件が充実してきたこともあって、テスト数自体もかなり増えてきました。 結果、テストの実行時間が長く「ci 通ったらマージしますね」などといった際の待ち時間が負担となっていました。 テストデータの削除方法を見直したり、テストを並列実行にするなどの対策を行い、40〜60 分 → 10分弱まで短縮できていました。 しかし、今回さらに TestProf というテストのパフォーマンスを分析してくれる gem を使って、テスト自体の無駄をなくす方向で試してみたところ、以下のような条件では「ほんとに実行してるかな？」と疑うレベルで効果がありました。 テストで使用するデータの数が多い テストパターンが多い 今日は、今回の改善で行ったことを、ご紹介します👀 Te
まえおき Railsでsystem specを導入するぞ！ というときに、Google検索をすると こういう記事が引っかかるかと思います。 単に「Cuprite使えばいいよ！」ではなく、そもそものシステムテストの必要性や開発経緯なども親切に書かれており、非常に素晴らしい記事です。 ただ、結果的にCupriteを称賛した内容で終わっており、人によっては「Seleniumなんか使わずにCuprite使えばいいんだ！」って思う人もいるかも知れません。 個人的にPlaywrightベースのCapybaraドライバを開発していて、その開発の際にCapybaraのソースとかCupriteの動作とか結構見たので、知見の共有をしておこうかなと思います。 SeleniumベースのCapybaraドライバ がスタンダード。それでも、Yet Another Capybaraドライバを求める理由はなんだっけ？ そ
幸いに登壇のチャンスがいただけたので、Kaigi on Rails 2023に現地参加してきました。 E2E testing on Rails 2023 by Yusuke Iwaki - Kaigi on Rails 2023 2年前の「システムテスト解剖学」という発表の続編的な位置づけで、RailsのE2Eテストを取り巻く技術の解説に徹する発表でした。 自分の発表のスタイルとして、「◯◯したらいいよ」「△△ライブラリ使うといいよ」系の発表にはしたくないというちょっとしたこだわりがあり、とはいえ今回の発表は手を抜くと「Playwright最高だよ、めっちゃいいよ」になってしまうので、注意深くストーリー展開を練って本番に望みました。 Node.jsベースのテストランナーを話す必然性 Railsで何をしたら幸せになれそうか？の定義 じつはあれもこれもしなくても、1個だけ仕組みを作ればいいんだ
僕が翻訳しているRSpecの入門本「Everyday Rails - RSpecによるRailsテスト入門」をアップデートしました。 すでに本書をお持ちの方はLeanpubから最新版をダウンロード可能です。 leanpub.com このエントリでは今回のアップデートの注目ポイントを5つ紹介していきます。 また記事の最後には期間限定の割引情報も載ってます！ 追記：記事内でお知らせしていた割引キャンペーンは2022年5月8日に終了しました。 【もくじ】 ポイントその1：サンプルアプリやサンプルコードが最新のRailsとRSpecに対応！ ポイントその2：統合テストをフィーチャスペックからシステムスペックに変更！ ポイントその3：ファイルアップロード機能をPaperclipからActive Storageに変更！ ポイントその4：その他、最新バージョンのgemを使うように内容をリニューアル！ ポ
Rails, RSpec でブラウザテストというと System Spec, Feature Spec などが挙げられます。バックエンド、フロンテエンド両方を End-to-End でテストするには便利ですが、複雑さ故に、たまに落ちるテストになってしまったり、落ちたときのデバッグが大変という難しさがあります。 Qiita でも主要な機能 (エディタ、記事ページなど) をテストするのに使っているのですが、CI で時折よくわからない理由で落ち、 更に何故落ちたかの再現や調査が難しい というのが結構つらいポイントでした 今回 Qiita で RSpec で利用するブラウザ自動化ツールを Selenium から Playwright を使うように置き換えたら、かなりデバッグが行いやすくなりました 移行自体も Cabybara 用の Driver を使うことで、大きく書き換えることなく移行することが
はじめに こんにちは、プレックスの種井です。 PlexJob開発チームではRSpecによるテストに使用するfixtureの作成に、FactoryBotを使用しています。 テストコードに対してはrubocop-rspecにより一定のルールに則ったコードが作成されていますが、Factoryの定義やオブジェクトの生成方法などは個々のメンバーに委ねられており、オンボーディングやコードレビューの際に方針に対して方針に対して疑問が上がる箇所になっていました。 今回、所属するチーム向けに運用やコーディングのルールを作成したので、この場を借りて紹介したいと思います。 目次 はじめに 目次 運用ガイド 運用の観点 運用時のルール 終わりに 参考資料 運用ガイド 前提と運用の観点 運用するにあたっての観点として「可読性」や「再利用性」はもちろんですが、DBへのアクセスを伴うこともあるため「パフォーマンス」にも
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
