Playwrightを運用する時は、「スモーク → 詳細」という
二段構成に分離することが望ましいです。
テストをこの2つのレイヤーで走らせることで、安定した自動テスト運用を構築することができます。
2段階レイヤーについて
1. スモークテスト（高速・最低限）
テストが壊れているかを判別することができます。
5〜20本のシナリオだけで「核心導線」を確認することができ、デプロイ後の事故をほぼ防ぐことができます。
2. 詳細テスト（重い・網羅的）
時間がある時だけ、夜間などに自動で走らせることで、無駄に重いテストを詰まらせないようにできます。
デプロイ前の一括チェックや、リリース前の最終防衛ラインなどでの実施で行うのが一般的です。
必要の是非
E2Eテストは、「遅い」「壊れやすい」「すぐ赤くなる」のマイナス3要素が存在します。
結合ポイントが多くて、UI変化の影響を受けやすい上、DB・API・ネットワークなど外部要因に引っ張られやすいという極めて困難なケースが少なくありません。
これら全部を1セットで毎回回すと失敗要因が増えすぎるんです。
構築サンプル : スモークテスト
最速（10秒から30秒程度）で終わる系の以下のようなテストです。
・ログインできるか
・主要ページが表示されるか
・基本のフォーム投稿が通るか
・エラーが出ないか
本当に壊れてないかだけを判定することが目的になります。
サンプルコード
// tests/smoke/login.spec.ts
test('ログインが成功する', async ({ page }) => {
await page.goto('/login');
await page.fill('#email', 'test@example.com');
await page.fill('#password', 'password');
await page.click('button[type="submit"]');
await expect(page).toHaveURL('/dashboard');
});
構築サンプル : 詳細テスト
時間のかかるテスト処理です。
・支払いパターン
・異常系フォーム
・フロント側のバリデーション
・UIパーツのビジュアルテスト
・エッジケース全て
サンプルコード
// tests/detail/form-validation.spec.ts
test('メール形式のバリデーション', async ({ page }) => {
await page.goto('/signup');
await page.fill('#email', 'wrong-email');
await page.click('button[type="submit"]');
await expect(page.locator('.error-message'))
.toHaveText('メールアドレスが不正です');
});
おすすめのディレクトリ構成
以下のようなディレクトリ構成にすることで、明確な棲み分けができます。
tests/
├ smoke/
│ ├ login.spec.ts
│ └ routing.spec.ts
└ detail/
├ form/
├ visual/
└ purchase/
・smoke は 速い・シンプル・壊れにくい
・detail は 網羅・時間がかかる・壊れやすい
CI での運用方法
・CI: pushされた → smoke だけ
・CI: 毎晩 / main マージ時 → detail 全部
1. Push → スモークのみ実行
プルリク自動チェックの際に、「壊れてないか」だけを即時検証します。
だいたい、数十秒〜1分で終わるぐらいの想定です。
2. 夜間またはmainマージで詳細テスト
長時間かかる（数分〜数十分またはそれ以上）網羅性チェックを検証します。
ビジュアルテストもここに含むことで、最終砦にします。
この構成のメリット
CI が高速化される
→ コミットのたびに10分テスト回すのは正直しんどい。
スモークの信頼性が高まる
→ “壊れていない”だけを保証する非常に大事な層になります。
詳細は開発チームの安心材料になる
→ バグを出しにくいチーム体制が作れます。
テストの保守が楽になる
→ detail が壊れても、すぐ対応する必要はない。
→ smoke だけは堅牢に守るようにします。
あとがき
実際に、WebサービスなどのE2Eテストを実行してみると、莫大な時間がかかってしまうことにビックリすると思います。
テスト検証のシートが増えれば増えるほど、テスト時間もどんどん増えていくので、モジュール追加、機能追加などに伴って、雪だるま式に膨らんでいくのが、E2Eテストです。
こうしたテストを、２段階のフェイズに分けるということで、開発者の負担を少なくするという二段構成の手法を学習してみました。
Gitを使った、「コミット→プッシュ→プルリク→デプロイ」という流れは、もはや開発作業の定石。
中でも頻度の高いコミットやプッシュは
短時間テスト、
実行回数が少ないけど本番に近くなる領域ほど
詳細テストを実行するという効率化につながります。
安定性ももちろん大事ですが、作業者負担を減らすというのも、効率化の一つなんですよね。
0 件のコメント:
コメントを投稿