フレーキーなテスト（Flaky Tests）

🎲 気まぐれなテストとの戦い方

成功したり失敗したり…不安定なテストの正体と対策

Flaky とは「不安定な」「気まぐれな」という意味です。

フレーキーなテストとは、
コードもテスト対象のWebサイトも何も変更していないのに、
実行するたびに成功したり失敗したりする、気まぐれなテストのことを指します。

✅

1回目：成功

❌

2回目：失敗

✅

3回目：成功

フレーキーなテストを放置してはいけない理由

一見すると、たまに失敗するだけの些細な問題に見えるかもしれません。

しかし、フレーキーなテストを放置することは、自動テストの土台そのものを腐らせてしまう、非常に危険な行為です。

フレーキーなテストが多いと、信頼は簡単に崩れます。

「いつもテスト失敗してるけど、メンテナンスしてるのかな？」

チームの誰もがこう思い始めると、会社としてテスト自体の信頼がなくなり、「やらなくてもいいんじゃない？」となります。

しっかりとメンテナンスされ、信頼できるテストだけが、品質を保証するのです。

もしメンテナンスができないのであれば、
自動テストはむしろ「無い方がまし」とさえ言えます。

⏰ バグの発見が遅れる

リグレッションテスト実行時に、本当のバグによる失敗が、フレーキーなテストの失敗に紛れてしまいます。原因を特定するまでに、余計な調査時間が必要になります。

⏰ テストの完了が遅れる

自動テストは、基本的に全てのテストが成功するまで完了しません。不安定なテストが一つでもあると、「成功するまで何度も再実行する」という不毛な作業が発生し、全体の完了時間がどんどん長くなります。

⏰ 無駄なメンテナンス作業が増える

自動テストは、その信頼性を保つために、基本的に毎日実行し、メンテナンスを行います。もし、そこに不安定な（フレーキーな）テストが混じっていると、再実行だけで1日の時間を大幅に削ってしまいます。

では、なぜこのような気まぐれなテストが生まれてしまうのでしょうか？

原因のほとんどは、以下のいずれかに分類されます。

⚠️ 問題

テストコードの実行速度が、Webサイトの表示速度よりも速すぎることが原因です。要素が表示される前に「見つからない」と判断してしまい、失敗します。

✅ 解決策

sleep（固定時間待機）のような曖昧な待ち方ではなく、expect を使って「〇〇が表示されるまで待つ」という、確実な待機方法を使いましょう。

⚠️ 問題

サイトの見た目（class）やHTMLの構造（場所）といった、変わりやすい情報に頼って要素を指定していることが原因です。デザインが少し変わっただけで、テストは壊れてしまいます。

✅ 解決策

getByRole や getByTestId など、ユーザーにとっての「意味」や「役割」に基づいた、変更に強い方法で要素を指定しましょう。

⚠️ 問題

テストが独立しておらず、他のテストの実行結果に影響を受けている状態です。実行する順番によって、成功したり失敗したりします。

✅ 解決策

各テストは、他のテストに一切依存せず、単体で完結するように設計します。テストに必要なデータは、そのテスト自身が実行前に準備（APIを使うなど）するのが理想です。

もし、気まぐれに成功したり失敗したりする「フレーキーなテスト」を見つけたら、それは**「見て見ぬふり」をしてはいけない、優先的に解決すべき問題**です。

自動テストの理想は、Fail率20%以下で安定して動作すること。
そのためにも、不安定なテストを見つけ次第、原因を調査し、修正するという日々のメンテナンスが欠かせません。

不安定さを一つずつ着実に解消していくこと。

その地道な努力こそが、信頼できる健全なテスト環境を築き、
プロジェクトを成功に導く鍵となります。