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

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しない - それは本物のリグレッションを隠す。