jsdom

The CSS rewrite was the result of 3 banked GPT-6 Astra Ultra resets, based on the work of a community member. See the mini-essay I wrote about it here: jsdom#4417 It resulted in 34 web platform test PRs, 11 @csswg issues, and comments on 7 existing CSSWG issues.

「とりあえず E2E」をやめたら、CI が 2 時間から 5 分になった話 はじめに 僕が個人開発している恋愛相談アプリ「Lovady」で、AI で書いたテストをとりあえず E2E に入れていたところ、CI が 1 回 2〜3 時間かかり、develop ブランチにマージするまで毎回 2 時間ほど待つようになりました。この話を X にポストしたら思っていた以上に反響があったので、Codex と一緒にテストを分け直したときの判断基準を改めてまとめてみました。 x.com 分け直して感じたのは、「何を保証するために、どこまで動かす必要があるか」でテストを選ぶと、E2E で確認すべきケースは思っているよりずっと少ないということです。 AI にテストを書かせていて CI が重くなってきた方や、単体テスト・コンポーネントテスト・E2E の分け方に迷っている方は、ぜひご覧ください。 題材にした恋愛相談アプリ「Lovady」の紹介 Lovady は恋愛の悩みを AI に相談できるチャットボットです。3 人の AI カウンセラーへの相談のほか、気になる相手のプロフィールを踏まえた相談や返信案の作成、相手が脈アリかどうかの診断機能、毎日使える恋みくじなどの機能があります。iOS アプリと Web 版があります。 もし興味があれば、ぜひ使ってみてください。 Web 版：lovady.app iOS アプリ：App Store この記事で紹介するのは Web 版のテストです。Lovady を作るのに使っている技術は次のとおりです。 Web 版：Next.js バックエンド：Python（FastAPI）をコンテナにして、Azure Functions で動かしています DB：SQL Server 認証：Firebase Authentication フロントエンドは、本人プロフィール・相手プロフィール・カウンセラーへの相談・脈あり診断・返信案生成・恋みくじの 6 つの機能ごとにディレクトリを分けています。 E2E に全部入れた結果 Lovady の Web 版では、AI にテストを頼むたびに Playwright（ブラウザを自動で操作するテストツール）の E2E が増えていきました。同じテストを Chrome・Firefox・Safari（WebKit）の PC 版と、Chrome・Safari のモバイル版の 5 種類で回していたので、件数は 1,726 件になっていました。 PR を出すたびに、この全件が走っていました。10月21日〜23日は 1 回 2〜3 時間かかる実行が 25 回あり、成功したのは 1 回だけでした。タイムアウトぎりぎりのテストが負荷で落ちることも多く、やり直すたびにまた 2〜3 時間待つことになり、完全にボトルネックになっていました。 ところが中身を見てみると、ローカルで済むものや、本来は単体テストに切り出すべきもの、jsdom だけで完結するバリデーションのテスト、1 画面だけで完結するテストばかりでした。Codex と 48 ファイル・325 件のテストを 1 件ずつ見直すと、149 件はコンポーネントテスト、34 件は単体テストで確認できる内容でした。バックエンドまでつないで確認すべきシナリオを抽出すると 10 件に収まりました。 また E2E に入れていたロジックだけのテストは、250 回分を合計しても 72 秒ほどで、時間のほとんどはブラウザで画面を操作するテストに使われていました... AI のおかげでテストを書く手間は減りましたが、実行時間とメンテナンスコストは減りません。Google のテストブログでも、E2E に頼りきる形を「アイスクリームコーン」と呼んで避けるべきパターンに挙げています。 「何を確認したいか」でテストを4つに分ける そこで、何を確認したいかでテストを4つに分けることにしました。単体テスト・コンポーネントテスト・E2E（API モック可）・E2E（実 API）の4つです。 ① ロジックの結果を確認したい → 単体テスト 計算結果や条件分岐、データの変換、バリデーションのルールそのものを確認したい場合です。画面を表示しなくても確認できるものは、まずここでテストします。 例：文字数が上限を超えたとき、入力値が無効と判定されるか ② ユーザー操作に対する画面の反応を確認したい → コンポーネントテスト（jsdom） 入力、クリック、エラー表示、ボタンの有効・無効など、コンポーネントの状態や表示を確認したい場合です。Lovady では Vitest と Testing Library に jsdom を組み合わせて使っています。 例：文字数が上限を超えた入力をしたとき、エラーメッセージが表示され、送信ボタンが押せなくなるか 実際のテストを簡略化すると次のような形です。 同じバリデーションでも、ルール自体は単体テストで、画面の表示や操作への反応はコンポーネントテストで確認しています。 補足：jsdom でできること・できないこと jsdom はブラウザを起動せずに Node.js の上で DOM を再現するライブラリです。Vitest の実行環境を jsdom にすると、React のコンポーネントを描画して、Testing Library で入力やクリックを再現できます。ブラウザもバックエンドも起動しないので E2E より速く、Lovady では develop 宛ての PR のたびに回しています。 一方で、jsdom は画面のレイアウトを計算しません。要素の位置や大きさ、見切れ、スクロール、CSS による見た目は確認できず、ページをまたぐ画面遷移も再現できません。こうした確認は次の③の E2E で行います。 ③ レイアウトや実ブラウザ固有の挙動を確認したい → E2E（API モック可） 画面のレイアウト、ブラウザ上での操作、複数画面にまたがる遷移などを確認したい場合です。 例：スマホ幅で操作ボタンが見切れずに表示され、クリックできるか 実ブラウザを使う場合でも、確認したいことによっては API をモックでき、毎回バックエンドまでつなぐ必要はありません。ただ、不用意にモックを挟むと、本来モックすべきでないテストまでモックしてしまうので要注意です。Lovady でも API はモックで、実際の保存までは確かめていないテストが混ざっていました。 ④ フロントからバックエンドまで実際につながることを確認したい → E2E（実 API） 認証して、画面を操作して、実 API を呼び、データが保存され、その結果が画面に反映される。こうした全体がつながって初めて成立する重要なユーザーシナリオを E2E で確認します。重要な異常系も対象にしますが、入力値の細かなパターンや条件分岐は単体テストやコンポーネントテストに任せています。 相談チャットの画面でテストを分ける Lovady の相談チャットでは、1 つの画面の中でも確認したいことごとに、次のようにテストを分けました。 4,001 文字を入力するとエラーになり、4,000 文字に直すと送信できる → コンポーネントテスト 送信に失敗しても入力が消えず、再試行できる → コンポーネントテスト 会話 A から B に移った後、遅れて届いた A の回答が混ざらない → コンポーネントテスト 入力・回答・日時の対応付けや並び順 → 単体テスト 文字数超過や存在しない会話を、API が受け付けない → API のテスト 相談を送って回答を読み、あとから会話を開き直せる → E2E（実 API） 実際の AI サービスから応答が返る → 実 AI の確認として分ける 長い E2E を丸ごと別のテストに移すのではなく、1 つのテストに混ざった確認を分けて、それぞれの置き場所を決めるのがオススメです。たとえば返信案の画面で「コピーする」を押す操作なら、選んだ案の文字列がコピー処理に渡ることはコンポーネントテストで、案を生成して選び、実際にコピーして使えることは E2E で確認します。 E2E は目的を達成する流れだけに絞る もちろん E2E がいらないわけではありません。画面・API・DB・認証を繋げて検証するのは E2E でしか確認できません。そのうえで、E2E で見るものは「利用者が目的を達成する一連の流れ」に絞ります。 バックエンドまでつなぐ E2E を 11 件に絞る Lovady でバックエンドまでつないで確認しているのは、次の 11 件です。 実行環境・認証・接続を確認する 自分のプロフィールを登録・更新して、再訪しても残っている 相手のプロフィールを登録・編集・選択・削除できる AI に相談して、回答が保存される 返信案を生成して、履歴から使える ゲストが同意して相談でき、会員はログアウト後に保護される 診断の結果を使って相談できる 言語を切り替えられる 恋みくじの結果が保存され、相談に使える ガイドの完了が保存され、ホームから相談へ進める ゲストが診断を受けて結果が保存され、再訪しても見られる この 11 件はテスト専用の認証環境・DB と本物のバックエンドにつなぎ、AI を使うケースだけは本物の AI も呼びます。テスト用の会員や DB は実行ごとに作って終わったら片付け、かつ不要なモックが紛れ込んでいないかも実行前に確認しています。 機能ごとに E2E を分ける E2E は機能ごとにも分けています。フロントエンドを 6 つの機能ごとのディレクトリに分けて E2E も同じ単位で置き、開発中は差分のある機能の E2E だけを回して、共通の部品を変えたときは全部を回します。 フロントエンドは軽微な修正がどうしても多いので、修正した機能の E2E をすぐ回せると、その機能の不具合を防ぎやすくなります。機能ごとに分けておけば、関係のない機能の E2E まで回す必要もありません。バックエンドのテストまで機能ごとに選んで回すかはまだ検討中ですが、フロントエンドは機能ごとに分けた方がテストしやすく、管理もしやすいと感じています。 テストケースを見直した結果 ブラウザを 5 種類から 4 種類に絞り、画面の細かな確認はコンポーネントテストと単体テストへ移して、価値の低い確認も外しました。その結果、リリース用の PR で回す E2E は 1,726 件から 60 件になりました。テストを回すタイミングも次のように変えています。 develop 宛ての PR：単体テスト・コンポーネントテスト・型チェック・lint だけを回す（5 分前後） 開発中：変更した機能の E2E だけを手元で回す リリース用の PR（develop → main）：E2E 60 件を 2 つのジョブに分け、それぞれ 2 並列で回す（全体で約 14 分）併せて 実 AI を利用する E2E も実行 テストを棚卸しするときのコツ 判断基準は 1 つのドキュメントにまとめて Skill から読ませる テストを残すかどうかは、デグレの起こりやすさ・壊れた場合の影響・今後の変更見込み・維持コストの4つで判断しています。この基準は 1 つのドキュメントにまとめ、テストを書くときや消すときに使う Skill からそこを読ませています。 AGENTS.md に書くと毎回読み込まれるので、テストに関係のない作業にも基準が入ってしまいます。これを防ぐために Skill にして切り出しています。 代わりのテストが通ってから E2E を消す E2E はいきなり消さずに、計画 → 代わりのテストの追加 → E2E の削除の順で進めます。バックエンドまでつなぐ E2E の手順はあらかじめ Skill にまとめておき、別のエージェントがその Skill だけで再実行できることを確かめます。そのうえで代わりのテストを実行させ、単体テストでも E2E と同じようにデグレを検知できることを確認しながら進めました。 E2E を書く前に仕様を一覧にしておく E2E を作る前に、画面設計や UI、画面遷移、状態、正常系と異常系を整理しておくのをオススメします！ どの入力をどう検証するか、どのタイミングで何をするかをざっくり把握できていると、「このチェックは単体テストの方がいい」と判断できます。 逆に、ここを決めずに AI に任せると、とりあえず全部を E2E で実装しがちです。バリデーションや通信エラーのときの動きなど、仕様を決めるならその場で一覧にして、それぞれをどこでテストするかを逆算して決めます。Markdown などで左に仕様、右にどこでテストするかを並べておくと、可読性高くレビューしやすいのでオススメです。 レビューでは E2E をシナリオだけに絞らせる テストのレビューで全部を見るのは大変です。ただ、単体テストとコンポーネントテストで粒度を分けておくと、レビューの負担はかなり減ります。レビューのときに不要な E2E を消させて、E2E には必要なシナリオのケースだけを残すと、E2E のレビュー負荷が減るのでオススメです。 E2E で本来見ないといけないケースの確認漏れも減るので、E2E を減らすことは改めて大事だと感じています。 おわりに E2E に何でも入れると、実行時間がそのまま開発のボトルネックになる 「何を保証するために、どこまで動かす必要があるか」でテストを選ぶ バックエンドまでつなぐ E2E は、つながって初めて成立する重要なユーザーシナリオに絞る AI にテストを任せるときは、分け方の基準を必要なときだけ Skill から読ませる E2E を絞っていくと、テストピラミッド（速い単体テストを多く、遅くて壊れやすい E2E は少なく持つ考え方）という古典的な考えに戻ってきました。AI でテストを書くのが速くなった今でも、この考え方はそのまま役に立つと感じています。E2E が重くなってきた方は、一度テストの中身を棚卸ししてみてください 参考資料 Martin Fowler「TestPyramid」 Google Testing Blog「Just Say No to More End-to-End Tests」 Playwright「Mock APIs」 Vitest「Test Environment」 jsdom（GitHub） Xフォローしてくれると嬉しいです Xでも情報発信しているので、フォローしていただけると励みになります！ x.com