😸

初めての E2EテストでPlaywrightを使った話

に公開
Test
Playwright
E2E
tech

今回プロジェクトでE2Eテストを経験したので、E2Eテストについてと、Playwrightの便利機能をまとめておきます。
自分用の備忘録ですが、まだE2Eテストをやったことがない人や、Playwrightを触ったことがないという人の参考になればうれしいです。

E2Eテストとは

E2E（End-to-End）テストは、ユーザーの操作を端から端まで通しで検証するテストで、
ログイン → 一覧表示 → 詳細遷移 → フォーム送信 → 成功のトースト…
のようなシナリオ単位でテストを実行します。

他のテストとの違い

  • 単体テスト: 関数やメソッド、クラス単位でのテスト
  • 結合テスト: 単体で動くものを結合するテスト
  • E2Eテスト: 実際のユーザー操作に沿って、一連の動作を検証するテスト

メリット

  • ユーザー体験を担保できる
    一連の流れをテストできるので、単体テストや結合テストではあぶり出せないバグを発見することができ、「ボタンが押せない」「モーダルが閉じない」など、ユーザーが直面するバグを捕まえやすいです。

  • 検証の効率化とリリース前の安全度向上
    リリース前になって、毎回モンキーテストでポチポチ検証するとなると手間なので、一度E2Eテストを作ってしまえばリリース前にテストを回すことでバグを洗い出せます。

シナリオを考える時のポイントは「ユーザーストーリー単位で書く」ことで
「メールとパスワードを入れる → 'ログインしました' が見える」みたいに、ユーザーの目線で確認できる結果をアサートするのが大事です。

デメリット

  • 構築コスト
    シナリオ設計、データ準備、セレクタ設計と準備に時間がかかってしまいます。

  • 壊れやすさ（フレーク）
    ボタンの位置やラベルが変わったり、読み込みの遅延だけでもテストが失敗することがあるので、堅牢なセレクタ設計やauto-waitを使う必要があります。

  • 実行時間が長い
    部品単位のテストより範囲が広いぶん、CIに組み込むとビルド時間が伸びてしまいます。

私が経験したプロジェクトでは、
テストを回すたびにデータが作られすぎて、画面やバッチ処理が重くなってしまい、バグではないところでテストが落ちてしまっていたので、クリーンアップはかなり大事だと思いました。
他記事ではCIが長くなることを懸念し長すぎるシナリオは避けて、重要な経路を優先するという意見も見られました。

Playwrightの便利な機能

実際にE2Eテストを書くときにPlaywrightがどう便利なのかをいくつか紹介します。

1. 主要ブラウザをサポート

  • Chromium / Firefox / WebKit を公式でサポートしているので、クロスブラウザテストが簡単に行えます
  • 「Chromeで動いたけどSafariで動かない…」という不安を減らせます

2. 自動待機（auto-wait）

await page.click('button#submit');
  • こんな感じで書くと、⚪︎秒待機のようなコードを書く必要がなく、要素が表示されたり、ボタンがクリックできるまで自動で待機してくれます。

3. セレクタが豊富 & 強力

  • getByRole、getByText、getByTestId など意味ベースで要素を指定可能
  • テスト専用の data-testid 属性と組み合わせると、壊れにくいテストが書けます

4. テストの記録・コード生成

npx playwright codegen <URL>
  • このコマンドでブラウザを操作すると、その操作を自動でコードに変換してくれるので、手動操作をベースにテストを素早く雛形化でき、初学者でも始めやすいです
    後述しますが、この機能がテスト初心者の私にはとても便利でした！

5. スクリーンショット・動画撮影

  • 失敗したテストでスクリーンショットや動画を自動保存可能で、「なんで落ちたのか」を目で確認できるので、デバッグ効率が大幅に上がります

6. 並列実行 & CI/CD連携

  • テストを並列に実行して時間を短縮
  • GitHub Actionsなど主要なCI/CDとの連携用テンプレートも用意されているので、導入がスムーズです

実際の使い方

テスト初心者の私が一番やりやすかったフローを書いておきます。

  1. QaseのシナリオをCursorにコピペ

    • 今回テストのシナリオはQaseで書かれていたので、Qaseのシナリオ手順をCursorにコピペ

  2. 既存実装ファイルも一緒にCursorに食わせる

    • すでに実装されているファイルも一緒にCursorに食わせて、「この実装をもとに新しいファイルを作成し、シナリオに沿ったテストを書いてください」
      というと大枠を作ってくれます。

  3. 要素の取得を修正

    • 要素の取得はうまくいかないことが多いので、npx playwright codegen <URL> を使って取得したlocatorを使って修正して、微調整するだけでテストコードが簡単に実装できます！

まとめ

E2Eテストはどうしてもコストが高くなりがちですが、ユーザー体験を担保するには最適なんだなと思いました。

ただし全部のシナリオを自動化する必要はなくて、リリース前に絶対壊れてほしくない「クリティカルな経路」に絞って実装するのが現実的だと感じます。

Playwrightはその負担を減らすための便利機能が揃っていて、テストコードのキャッチアップコストを減らせるのが大きなメリットです。

特に初心者でも codegen や auto-wait を使えば形にしやすいので、まずは重要なフローだけでも導入してみると効果を実感しやすいと思います！

Discussion