flakyテストダッシュボードとは？わかりやすく解説

flakyテストダッシュボードは、どのテストが一貫せずに合格・失敗するのか、そしてどのくらいの頻度でそうなるのかを追跡し、散在して忘れられがちなflakeを、ランク付けされた可視のリストへと変えます。

flakyなテストは、失敗を1つずつ見れば無視しやすく、まさにそれが原因で放置され続けます。ダッシュボードは、多数の実行にわたってflakeを集計することで、この問題を無視できないものにします - どのテストが最悪なのか、状況が改善しているのか、そしてどこに労力を投じるべきかが見えるようになります。

何を示すのか

直近の実行にわたって、どのテストの結果が一貫していないか。
テストごとのflakiness率（コード変更なしにどのくらいの頻度で失敗するか）。
時系列の傾向：全体のflakinessは上昇しているのか、それとも低下しているのか。
どのflakeが最も多くのmergeをブロックしているか - 修正の優先順位付けのため。

なぜ可視化が記憶に勝るのか

どのテストがflakyかを人の記憶に頼るのは失敗します - その知識は属人的で、断片的で、人員の入れ替わりで失われます。ダッシュボードは、flakinessを測定された共有の事実にします。目標を設定し、明確な隔離リストを維持し、問題が改善しているかどうかを証明できます。

チームはどう使うか

ダッシュボードは優先順位付けを推進します - 最もflakyで、最もブロックの多いテストから修正しましょう。ブロックする経路から何を外すべきかを教えてくれ、隔離の判断にも役立ちます。さらに説明責任をもたらし、隔離されたテストが黙って永遠に積み上がるのではなく、修正されて元に戻されるようにします。

flakyテスト vs インフラのノイズ

優れたダッシュボードは、テストのflakinessを環境ノイズから切り分けます。runnerがメモリ不足になったり、registryがタイムアウトしたりしたためだけに「失敗」するテストは、flakyなテストではありません。それは一時的なインフラ障害です。この2つを混同すると、実際にはプラットフォームの問題であるものを、テストのバグとして追いかけることになります。

Latchkeyの視点

一時的および機械的な障害を自動的にリトライし、一度きりの不具合であなたのbuildが失敗しないようにすることで、Latchkeyの自己修復マネージドrunnerは環境ノイズをあなたのflakyテストダッシュボードから排除します。その結果、リストにはインフラが原因の失敗ではなく、本当にflakyなテストが反映されるようになります。

重要なポイント

flakyテストダッシュボードは、断続的なテストとそのflakiness率を追跡します。
忘れられがちな単発のflakeを、可視でランク付けされた問題へと変えます。
優先順位付け、隔離の判断、そして説明責任を推進します。
テストのflakinessをインフラのノイズから切り分けることが不可欠です。