フレーキーテスト（Flaky Test）

フレーキーテストは、同じコミットに対して異なる結果を返すテストです。変更していないコードに対して 10 回実行すると、成功と失敗が混ざります。決定的な特徴はプロダクトが何も変わっていないことで、結果のばらつきはテスト自体、そのデータ、またはその環境から生じています。

なぜ問題なのか

フレーキーテストがいくつか含まれるスイートは、チームに「緑になるまで失敗を再実行する」習慣を植え付けます。その習慣が根付くと、本物の回帰も再実行で流されてしまいます。また、再試行で実行時間が膨らむためパイプラインが遅くなり、カバレッジ不足よりも速いペースで自動化への信頼を損ないます。

よくある原因

• タイミング。 ページや API の準備が整う前にテストが操作してしまう。固定の sleep、再試行せずに一度だけ値を読むチェック、実行中のアニメーションなどです。
• 共有状態。 2 つのテストが同じユーザー、カート、データベースの行に書き込む。単独では成功し、並列実行や順序が変わると失敗します。
• テスト順序への依存。 先に実行されたテストが作ったデータに依存している。
• 環境。 遅い、または共有のテスト環境、外部サービス、レート制限、タイムゾーンや時計の変更。
• 非決定的なデータ。 シードを記録していないランダムな入力や、「現在時刻」に対するアサーション。

対処方法

1. 再現します。単一のテストをループで実行し（Playwright なら npx playwright test my.spec.ts --repeat-each=20）、失敗した実行のトレースや動画を取得します。
2. リトライを追加するのではなく原因を見つけます。スリープを条件ベースの待機（Playwright の Web ファーストアサーションや Selenium の WebDriverWait など）に置き換え、各テストに専用のデータを持たせます。
3. 今日中に直せないなら隔離（クオランティン）します。ブロッキングのゲートから外し、オーナーを決めた非ブロッキングの追跡用ジョブに移して、メインのシグナルの信頼性を保ちます。
4. フレーキー率を継続的に追跡します。リトライで成功したテストは、レポートに表示されない限り問題を覆い隠します。

リトライ（playwright.config.ts の retries: 2）は CI での妥当なセーフティネットですが、リトライでしか成功しないテストはやはりフレーキーです。Playwright はそうしたテストを「flaky」として報告するので、把握できます。