flakyなテストとは？

flakyなテストとは、何の変更もないのに同じコードで合格したり失敗したりするテストで、信頼できない非決定的な結果を生みます。

flakyなテストは、コードが何も変わっていなくても、合格することもあれば失敗することもあります。flakinessは腐食的です。開発者に赤いbuildを無視するよう仕向けますが、それはまさに本物の失敗がすり抜けるときです。よくある原因を理解することが、それを排除する第一歩です。

テストをflakyにするもの

非同期操作間のタイミングと競合状態。
テストの実行順序や共有状態への依存。
実時刻、乱数、ネットワークへの依存。
UIテストにおける不安定なセレクタや固定のsleep。

なぜflakinessはこれほど有害なのか

flakyなスイートはCIへの信頼を損ないます。赤いbuildが時に無意味だと、人々はグリーンになるまで再実行したり失敗を無視したりし始め、本物のリグレッションがノイズに紛れます。そのコストは、無駄な再実行だけでなく、セーフティネット全体への信頼の喪失です。

よくある例

条件を待つ代わりに固定時間だけ待つテストは、高速なマシンでは合格し、低速なマシンでは失敗します。これは典型的なタイミングのflakeです。

A timing flake and its fix

await sleep(100);        // flaky: hopes 100ms is enough
await waitFor(() => ready); // stable: waits for the condition

flakinessを根本で修正する

永続的な修正は非決定性を取り除くことです。sleepの代わりに条件を待ち、テスト間で状態を隔離し、時刻と乱数をstub化し、テストの順序に決して依存しないことです。自動リトライは一時的なflakeを覆い隠せますが、頻繁にflakeするテストは、永遠にリトライするものではなく、修正すべきバグです。

flakyなテストとCI

CIはflakinessが最も痛むところです。mergeをブロックし、再実行でrunner時間を消費するからです。実用的なアプローチは二本立てです。決定的なflakeを修正し、真に一時的な失敗を自動リトライして、一度きりのネットワークの不調が良いbuildを失敗させないようにします。Latchkeyはまさにその理由で一時的なflakeを自動リトライしつつ、修正できるよう持続的にflakyなテストを表面化させます。

重要なポイント

flakyなテストは、同じコードで非決定的に合格したり失敗したりします。
CIへの信頼を損ない、本物のリグレッションをノイズに紛れさせます。
決定的なflakeは根本で修正し、真の一時的なものは自動リトライします。