プログラミングを仕事で行う時に、品質保証を行う最低限のお作法は、テストコードです。
最近では、それの上位版の「自動テスト」は、当たり前になってきました。
gitのfooksを利用して、コミット、プルリク、push、pull、至る所のイベントをフックにして、
自動的に不具合を検知する仕組みは、安心できるデプロイにつながります。
そして、サーバーサイドのPHPなどにおける単体テストから、ある程度の結合テストは、簡易に構築できますが、
Webシステムにおけるブラウザテストって、これまでは、Seleniumの一人勝ち状態でした。
GoogleがChromeブラウザにおける、Pupetterも悪くないんですが、Playwrightの方がブラウザ対応も機能も豊富なので、徹底的にPlaywrightを学習してみようと思い、
学習手順を考えてみました。
学習手順
1. 最初に「公式の実行フロー」を掴む
Test Runner、BrowserContext、Page、Locator の役割を理解する。
特に “自動待機（auto-wait）” と “await 必須箇所” を把握。
2. 録画からコード生成で全体像をつかむ
npx playwright codegen https://your-service.com
UI操作 → コード生成の流れで「どんなAPIがあるか」を一気に把握。
3. Page/Locator の使い方を強化する
locator のベストプラクティス（role, text, data-testid）に慣れる。
あなたのサービス側に data-testid を追加しておくと、テストが安定しやすい。
4. テストの骨格テンプレートを先に作る
・ログイン処理
・権限チェック
・共通ヘッダ・メニュー周り
・各画面の基本操作
これらを “共通モジュール化” しておくと E2E が劇的に楽。
5. Before/After Hooks で環境セットを自動化
毎回ログインしないように storageState を活用。
テスト開始前に「固定データ登録」「環境クリア」を自動化。
6. CI 実行を早めに導入する
GitHub Actions / GitLab CI で早期に回す。
ローカルで動いても CI で落ちる…はよくあるので「最初からCI前提」で学ぶ。
7. 安定化テクニックを早期に吸収する
明示的 wait を減らす。
selector の揺れを避ける。
リダイレクトやSPAの非同期に強いパターンを覚える。
8. ビジュアルテストを取り入れる
toHaveScreenshot() を活用して画面崩れを検知。
大規模UIなら大きな効果。
9. 運用時の二段構成について
デプロイ時 → スモークテスト
深い操作 → 夜間定期バッチ
運用負荷が下がる。
10. プロジェクト固有の Page Object モデルを導入する
ログインページ・一覧ページ・詳細ページ…の抽象化。
テストコードが読みやすくなり、変更にも強くなる。
11. 自分のサービスの操作マップを作る
・重要導線（登録→確認→完了）
・クレームが多い箇所
・UI変更が頻出する画面
この3つから先にテストを書くと、学習 + 価値が両立する。
最短で「実務投入」まで進める流れ
1. Playwright の QuickStart + codegen で動作とAPIを理解
2. ログイン処理だけ別モジュール化（最初の山場）
3. CI に流して「落ち方」を知る
4. スモークテスト（5本程度）をまず完成
5. 安定化ノウハウを吸収しながら詳細テストへ拡張
Webサービスを前提にしたテスト設計プラン（テンプレート）
1. 最初に作るべき「導線マップ」
・ログイン → ダッシュボード
・一覧 → 詳細 → 更新 → 保存
・登録 → 確認 → 完了
・検索 → フィルタ → 結果確認
・設定画面 → 値変更 → 永続チェック
上記はほぼすべてのWebサービスで共通する“核”の導線。
この導線単位で Playwright のテストケースを構築する。
2. 画面カテゴリ別テスト設計
A. 認証系（最優先で作る）
・ログイン成功
・パスワード間違い
・未ログイン状態で保護ページへアクセス → リダイレクトされる
・ログアウト後の再アクセス → 防止されている
・役割（管理者 / 一般ユーザー）の出し分け
テスト価値が高いので最初に自動化する領域。
B. ダッシュボード（初期ホーム）
・レイアウト崩れの検知（スクリーンショット比較）
・最新データが正しく表示される
・メニュー → 各画面への遷移動作
・API エラー時のエラーメッセージ有無
日々動く画面のため、視覚テストとの相性が良い。
C. 一覧画面
・データがページング/スクロールで適切に表示
・並び替え（昇順/降順）
・フィルタリング
・検索キーワードの一致
・クリック → 詳細ページの遷移
不具合が多い領域なので網羅度を上げる価値がある。
D. 詳細画面
・レコードID に応じて正しい情報が表示されている
・編集ボタン → 編集画面に遷移
・削除 → モーダル確認 → 一覧へ戻る
・不正なID（例: /detail/99999）→ エラー表示
ID 誤取得や API 不整合によるバグを防ぐ。
E. 登録・更新フォーム
・必須項目未入力のバリデーション
・形式エラー（メール形式 / 文字数）
・正常値入力 → 登録成功
・登録後のリダイレクト（ありがとうページなど）
・更新後の差分反映
・モバイル幅での崩れ（レスポンシブテスト）
E2Eの中で最も「目視テストの工数を削減できる領域」。
F. 設定画面（永続性テスト）
・値更新 → 再ログインしても保持されている
・フラグ（ON/OFF）の反映
・クライアント側のキャッシュクリア時も正しく動作
API が落ちたときのエラー UI
G. 二次機能（通知 / ファイル / CSV）
・CSV import → 期待通りの登録
・CSV export → 正しいデータ
・通知バナー（成功 / 失敗）が出る
モーダル・ダイアログの挙動
3. 優先度（P1 → P3）
P1（デプロイ前に常に回す）
・認証
・メイン導線（一覧 → 詳細 → 更新）
・新規登録の成功シナリオ
P2（デイリーまたはリリース時のみ）
・フィルタ・検索
・設定画面
・削除・例外動作
P3（週次や夜間バッチ）
・レスポンシブテスト
・スクリーンショット比較
・非主要導線
4. Playwrightでの構造（推奨フレーム）
tests/auth/
tests/dashboard/
tests/list/
tests/detail/
tests/form/
tests/settings/
Page Object モデルはこう分ける
pages/LoginPage.ts
pages/DashboardPage.ts
pages/ListPage.ts
pages/DetailPage.ts
pages/FormPage.ts
共通ユーティリティ
helpers/loginState.ts（storageState 永続化）
helpers/wait.ts（安定化処理）
helpers/faker.ts（テストデータ生成）
5. 自動化運用フロー
PR 作成 → スモークテスト（P1）
main 反映 → P2 まで実行
夜間の定期 → フルテスト（P1〜P3）
こうする事で、「開発速度を下げずに E2E を最大限活用」できる運用が作れる。
あとがき
学習手順が定まったら、あとはひたすら学習を進めるだけです。
わからないことが分かったら、モチベーションもアップするし、実務効率もアップします。
効率が上がれば、時間の余裕が生まれて、時間の余裕が生まれたら、他の色々な事ができるようになります。
う〜ん、早く学習完了したくなってきた・・・
0 件のコメント:
コメントを投稿