1. 導入：なぜFlaky Testを放置してはいけないのか
開発スピードを上げるために導入したCI/CDパイプライン。しかし、「特にコードを変更していないのに、なぜかテストが落ちる」という経験はありませんか？これが「Flaky Test（不安定なテスト）」です。Flaky Testを放置すると、開発者は「またどうせ不安定なテストだろう」とエラーを無視するようになり、本当に重要なバグを見逃す原因になります。本記事では、この信頼性を損なうFlaky Testを制御し、パイプラインの安定性を高める方法を解説します。
2. 基礎知識：Flaky Testとは何か
Flaky Testとは、同じコード・同じ環境で実行しているにもかかわらず、ある時は成功し、ある時は失敗するテストのことです。主な原因には以下のようなものがあります。
・ネットワークの遅延：外部APIからのレスポンスが想定より遅い。
・非同期処理：UIの描画完了前に要素をクリックしようとしている。
・リソース競合：テスト並列実行時にDBのデータが他のテストと干渉している。
これらは完全にゼロにするのが理想ですが、現場では「制御可能な仕組み」を導入して被害を最小限に抑えるのが現実的です。
3. 実装/解決策：Playwrightを活用したリトライ戦略
現代のE2Eテストにおいて最も強力な対策の一つが、テストツール側の「自動リトライ」機能です。Playwrightを例に挙げると、設定ファイルで簡単にリトライ回数を定義できます。
4. サンプルプログラム：Playwrightでの設定例
以下のコードは、playwright.config.tsファイルで「テストが失敗した際、最大2回まで自動でリトライする」設定例です。
// playwright.config.ts
import { defineConfig } from ‘@playwright/test’;
export default defineConfig({
// 失敗時に何回まで再試行するかを指定（CI環境では2回、ローカルでは0回にするのがおすすめ）
retries: process.env.CI ? 2 : 0,
// 並列実行の設定
workers: process.env.CI ? 1 : undefined,
use: {
// タイムアウト設定：テストが不安定になりやすい箇所は少し長めに設定する
actionTimeout: 10000,
navigationTimeout: 15000,
},
});
5. 応用・注意点：現場で陥りやすい罠
自動リトライは強力ですが、万能ではありません。注意すべきポイントは以下の通りです。
・「根本解決」を忘れない：自動リトライはあくまで応急処置です。頻繁にリトライが発生するテストは、コード自体に「待機処理（waitForSelectorなど）」が不足していないか、必ず見直してください。
・副作用に注意：DBへ書き込みを行うテストの場合、リトライによってデータが二重登録される可能性があります。テストデータはテストごとに独立させる（クリーンアップ処理を徹底する）ことが不可欠です。
・CI側の再実行機能：GitHub Actionsなどを使用している場合、ツール側のリトライだけでなく、失敗したジョブのみを再実行するボタンを活用しましょう。
Flaky Testと正しく向き合うことは、チームの心理的安全性を高め、開発体験を向上させるための第一歩です。まずはリトライ設定から導入し、少しずつテストの品質改善に取り組んでいきましょう。
コメント