CIにおけるFlakyテスト: 原因、検出、封じ込め

著者 Kaveh Alemi·Latchkey

flakyなテストは同じコードでpassしたりfailしたりします。管理されないまま放置すると、不安定さはCIへの信頼を蝕み、やがて赤いbuildが何も意味しなくなります。

flakyなテストは非決定的です。その結果はテスト対象のコード以外の何かに依存します。これらは腐食的です。なぜならチームに失敗を無視するよう仕向けるからです - CIの目的とは正反対です。

よくある原因

race conditionとタイミングの前提(sleepベースの待機)。
テストの順序への依存と共有された可変状態。
実際のネットワーク、時計、外部サービスへの依存。
リソースの逼迫(遅く負荷のかかったrunnerがtimeoutを超過する)。

不安定さの検出

run全体にわたってテストごとのpass/failの履歴を追跡します。同じcommitでfailしてからpassするテストは、定義上flakyです。既知の良好なcommitでスイート全体を繰り返し再実行すると、最悪の要因が浮かび上がります。

バグを隠さずに封じ込める

既知のflakyなテストをquarantineしてmergeをブロックしないようにし、根本の非決定性を修正するチケットを起票し、既知のflakyなテストにのみ制限付きretryを適用します。原則は、ノイズをretryし、決してシグナルをretryしないこと - 一貫して再現する失敗は常に表面化しなければなりません。

重要なポイント

flaky = 非決定的。結果はコード以外の何かに依存する。
テストごとの履歴で検出する。同じcommitでのfail-then-passがその兆候。
quarantine + 対象を絞ったretryで封じ込め、根本原因を修正する。
決してすべてを一律にretryしない - それは本物のリグレッションを隠す。

よくある質問

What is Flaky tests in CI?

Flaky tests are nondeterministic: their result depends on something other than the code under test. They are corrosive because they train teams to ignore failures - the opposite of what CI is for.

Detecting flakiness?

Track per-test pass/fail history across runs. A test that fails and then passes on the same commit is flaky by definition. Re-running the whole suite repeatedly on a known-good commit surfaces the worst offenders.

Containing it without hiding bugs?

Quarantine known-flaky tests so they do not block merges, file tickets to fix the root nondeterminism, and apply bounded retries only to tests known to be flaky. The principle: retry the noise, never the signal - a consistently reproducing failure must always surface.