本物のバグを隠さずにflakyなテストをquarantineする方法

quarantineとは、既知のflakyなテストを削除せずにmergeをブロックするパスから引き離す規律です - こうしてbuildの信頼性を保ちながら、修正すべきテストとして記録に残しておきます。

テストが明らかにflakyだと分かったとき、悪い選択肢が3つ(無視する、削除する、mergeをブロックさせる)と、良い選択肢が1つあります: quarantineです。正しく行えば、coverageを失わずにノイズを取り除けます。

削除や永久retryではなくquarantineする理由

flakyなテストを削除すると、flakyでないときに提供していたcoverageを失います。一律のretryは本物の回帰を隠します。mergeをブロックさせ続けると、赤いbuildを無視するようチームを慣らしてしまいます。quarantineはその針の穴を通します: テストは依然として実行されレポートしますが、その結果はもはやmergeのgateにはなりません。

quarantineの方法

テストにタグを付け(例えば quarantine/flaky マーカー)、runnerが分離できるようにします。
quarantineされたテストは、レポートはするがbuildを落とさない非ブロッキングのレーンで実行します。
quarantineした瞬間に、そのテストに紐づく追跡チケットを起票します。
テストを実行し続けて、どれくらいの頻度でまだflakyになるかのデータを収集します。

誠実さを保つ

quarantineは一時的で可視でなければ、死んだcoverageの墓場になってしまいます。テストがquarantineに留まれる期間に上限を設け、quarantineリストをdashboardに表示し、期限が切れたら修正か削除かの判断を必須にしましょう。flake管理の原則が当てはまります: ノイズは封じ込め、シグナルは決して黙らせないこと。

戻すか削除するか

根本の非決定性が修正されたら、テストをブロッキングスイートに戻し、多数の実行にわたって安定していることを確認します。決定論的にできず、かつ固有のものを何もテストしていないなら、意図的に削除しましょう - 永久にquarantineされた亡霊よりも、誠実な削除のほうがましです。

重要なポイント

quarantineは既知のflakyなテストをブロッキングパスから外しつつ、実行は続けます。
ノイズがmergeのgateになったり回帰を隠したりさせずに、coverageを保ちます。
quarantineは必ず追跡チケットと期限とセットにしましょう。
修正できたら戻し、そうでなければ意図的に削除しましょう - 永久的な亡霊を決して残さないこと。