ビルドが赤くなり、誰かが「再実行」をクリックするとビルドは成功し、全員が先に進みます。無害に見えますが、不安定なテストは、テスト スイートが持つ最も価値のあるもの、つまりテスト スイートに対する人々の信頼をゆっくりと破壊します。通常、障害はノイズですが、実際のバグも紛れ込みます。

このガイドでは、テストが不安定になる理由と、それぞれの原因を適切に修正する方法について説明します。 Python 3.13 でタイミングと共有状態のデモを実行し、表示された数値はそれらの実行から得られました。これらは不安定さをわかりやすくするために設計された小規模なデモンストレーションであるため、ご自身の失敗率は異なります。

不安定なテストとは何ですか?

不安定なテストでは、同じコードに対して異なる結果が得られます。製品に何も変更がなかったとしても、ある実行では成功し、次の実行では失敗します。テストに問題があるか、コードに実際の断続的なバグが含まれている可能性があります。この 2 番目の可能性こそが、単純にそれらを無視すべきではない理由です。

不安定なテストはなぜ非常にコストがかかるのか

• 信頼の喪失。 人々は、赤が「おそらく不安定」であることを意味すると考えると、実際の失敗を調査するのをやめます。
• 時間の無駄。 開発者はパイプラインの再実行と、変更とは関係のない障害の調査に何時間も費やします。
• 配信が遅くなります。再実行時にマージと待機が解除され、CI/CDのポイントが損なわれます。
• 隠れたバグ。 製品内の競合状態はテスト ノイズのように見える場合があり、これらは実稼働環境に害を及ぼすものです。

Common causes at a glance

原因 1: スリープのタイミングと固定

これが最も一般的な原因です。テストでは、バックグラウンド作業が一定の遅延後に完了すると想定しています。効果を確認するために、作業に最大 2 ミリ秒かかる小規模なテストを作成しましたが、テストはチェックするまでにわずか 1 ミリ秒待機します。

def flaky_timing():
    result = {}
    def work():
        time.sleep(random.uniform(0, 0.002))
        result["done"] = True
    threading.Thread(target=work).start()
    time.sleep(0.001)        # hope it has finished
    assert result.get("done")

修正するには、上限を十分に設定して実際の状態を待つことです。

def fixed_timing():
    result = threading.Event()
    def work():
        time.sleep(random.uniform(0, 0.002))
        result.set()
    threading.Thread(target=work).start()
    assert result.wait(timeout=1)   # continues as soon as it is ready

各バージョンを 200 回実行しました。

その結果、単なる信頼性以上のものが得られます。修正バージョンは作業が完了するとすぐに処理が進むため、通常は高速化されます。スリープを長くすると、最初のバージョンが失敗する頻度は減りますが、毎回の実行が遅くなり、ビジー状態の CI マシンでは依然として失敗する可能性があります。

ブラウザテストでも同じ原則が当てはまります。 time.sleep の代わりに、Playwright の自動待機、または明示的な Selenium 待機 を使用します。

# Playwright: retries until true or a timeout is reached
expect(page.get_by_text("Order placed")).to_be_visible()

# Selenium: an explicit wait for a condition
WebDriverWait(driver, 10).until(
    EC.visibility_of_element_located((By.ID, "confirmation"))
)

原因 2: 状態とテスト順序の共有

テストがデータを共有する場合、一方が他方に影響を与える可能性があり、結果は実行順序によって異なります。これら 2 つのテストは 1 つの共有リストを使用します。

store = []

def test_add():
    store.append("x")
    assert len(store) == 1

def test_empty():
    assert store == []

私たちの実行によりこれが確認されました。これが、スイートが何か月も経過しても、誰かが並列実行やランダムな順序のプラグインを追加すると壊れる可能性がある理由です。治療法は隔離です。

• テストをセットアップしてクリーンアップするフィクスチャを使用して、各テストに新しいデータを与えます。 pytest チュートリアル ではその方法を示しています。
• 共有の「テスト ユーザー」の代わりに、ランダムなサフィックスが付いた電子メールなどの一意のレコードを作成します。
• 設定で許可されている場合は、データベース テストを トランザクション でラップし、ロールバックします。
• これらの問題が早期に現れるように、定期的にテストをランダムな順序で実行してください。

原因 3: 日付、タイムゾーン、ランダム性

1 週間を通して合格したテストでも、土曜日、深夜、または月の最終日に不合格になる可能性があります。ロジック内の時計を読み取るのではなく、時間を入力にします。

def is_weekend(today=None):
    today = today or datetime.date.today()
    return today.weekday() >= 5

is_weekend(datetime.date(2026, 11, 7))   # True  (a Saturday)
is_weekend(datetime.date(2026, 11, 9))   # False (a Monday)

これらのテストでは、いつでも同じ答えが得られます。同様に、テストでランダムな値に固定シードを設定し、ランダム データを使用するときにそれをログに記録して、障害を再現できるようにします。セット、外部ソースからの辞書、または ORDER BY のないデータベース クエリからの特定の順序を想定しないでください。

原因 4: セレクターが壊れやすい

div:nth-child(3) > span のボタンを見つけるテストは、レイアウトを微調整すると中断され、一部の画面サイズまたはバリアントでのみ失敗する可能性があります。ユーザーに表示される内容、または専用のテスト属性に基づいてロケーターを優先します。 Playwright locators のガイドでは、それらを試す順序について説明しています。アニメーションもよくあるトラブルの原因であるため、テスト環境ではアニメーションを無効にすることを検討してください。

原因 5: 外部サービスとネットワーク

テストで実際の決済プロバイダーまたはサードパーティ API を呼び出す場合、その結果は他のユーザーの稼働時間とレート制限に依存します。ほとんどのテストではそれらの呼び出しをモックし、実際のサービスに対して少数の個別のコントラクト チェックを保持して、変更があった場合に学習できるようにします。私たちのガイド単体テストと統合テストこれらを分割する方法を説明します。

不安定なテストを診断する方法

1. 確認します。 変更せずにテストを何度も実行します。 pytest では、単純なシェル ループが機能し、pytest-repeat などのプラグインを使用すると --count=100 が得られます。
2. 証拠を記録します。 失敗ごとにログ、スクリーンショット、トレースを保存します。 Playwright のトレース ビューアはここで特に役立ちます。
3. 条件を重視します。 限られた CPU で並列またはランダムな順序で実行します。失敗を多くすることで勉強しやすくなります。
4. 単独でテストします。 常に単独で成功するが、スイートでは失敗する場合は、共有状態が疑われます。
5. パターンを探します。どのマシン、時刻、近隣のテストが関係しているかを確認します。
6. 製品を確認してください。これがアプリケーションで実際の競合状態である可能性があるかどうかを正直に尋ねてください。

自動再試行は修正ですか?

再試行は短期的なセーフティネットとしては役立ちますが、治療法ではありません。 CI で 1 回の自動再試行を行うと、調査中に作業を続行できますが、合格するために再試行が必要なテストでも何かがわかります。さらに悪いことに、20% の確率で失敗する実際の断続的な製品のバグは、通常は気付かれずに再試行されてしまいます。

次のルールで再試行を使用します。再試行を 1 つまたは 2 つに制限し、再試行が必要なすべてのテストを記録し、そのリストを To Do リストとして扱います。 「再試行で合格」と報告されたテストは、成功ではなく、調査すべき問題としてカウントされる必要があります。

不安定なテストのためのチームプロセス

1. 測定。 どのテストが失敗し、同じコミットで成功するかを追跡します。多くの CI ツールやテスト レポーターでこれを確認できます。
2. 隔離。 確認済みの不安定なテストをブロッキング実行から移動します。これにより、全員の混乱を防ぐことができますが、実行と追跡は続けてください。
3. 所有者と期限を割り当てます。 期限のない隔離は単なる墓場となります。
4. 修正または削除。 テストを修正する価値がない場合は、削除し、そのカバレッジが他の場所にまだ存在することを確認します。
5. 防止。 マージ前に新しいテストを数回実行します。 50 回の実行に 1 回失敗するテストは、6 か月かかるよりも今の方がうまく検出できます。

不安定なテストをバックグラウンド ノイズとしてではなく、優先的にバグとして扱います。 重大度と優先度で説明されているように、重大度と優先度はここにも適用されます。脆弱性が蔓延している場合は、より広範なテスト自動化の間違いについて読み、ブラウザ レベルでテストが多すぎるかどうかを検討してください。

まとめ

不安定なテストはランダムに感じられますが、実際にはランダムであることはほとんどありません。ほぼすべての人が、時間、順序、データ、環境についての仮定にたどり着きますが、それは必ずしも真実ではありません。今週パイプラインで最も頻繁に失敗するテストを選択してください。 50 回実行して仮定を見つけ、それを永久に修正します。 1 つの実際の修正は、チームに 100 回以上の再実行を教えることになります。

よくある質問

学び続ける