本当に問題を検知できるテストの書き方

パスするテストを書くのは簡単です。しかし、テスト対象の機能が壊れたときだけ失敗するテストを書くことは、多くのエンジニアが認めている以上に難しいことです。

失敗すべきときにパスするテストは、テストがないよりも有害です。それは根拠のない自信を生み出します。エンジニアはテストスイートが自分たちを守ってくれると思い込んでコードをマージします。しかし実際にはそうではありません。バグはリリースされ、テストはパスし続け、障害は本番環境で表面化します。そのとき、なぜテストが検知できなかったのか、誰もすぐには理解できません。

これは「失敗感度が欠如したテスト」と呼ばれます。よくある問題であり、真剣に向き合う価値があります。

テストが失敗しない理由

最もよくある原因は、誤った対象に対してアサーションを行うことです。「フォーム送信後にユーザーが成功メッセージを確認できること」というテストで、クラス名 message を持つ要素の存在に対してアサーションを行う場合、そのメッセージが「Success」であっても「Error: something went wrong.」であってもテストはパスします。そのアサーションは、関連する失敗を検知するには広すぎるのです。

サイレントな例外処理も一般的な原因です。テスト内の try/catch ブロックが例外を握りつぶして true を返すと、すべての実行パスがパスになります。エラーをキャッチしてデフォルト値を返し、失敗を伝播させないテストヘルパーは、アプリケーションの動作に関係なく、テストを絶対に失敗させないものにしてしまいます。

非同期テストにおけるレースコンディションは、断続的な感度の問題を引き起こします。非同期処理の完了前に結果を確認するテストは、失敗を検知する場合（処理が完了すべきタイミング後にチェックが実行されたとき）と見逃す場合（チェックが処理前に実行されたとき）が混在します。その結果、テストは安定して失敗するのではなく、散発的に失敗するようになります。これはエンジニアを、その失敗をフレークとして片付けるよう誘導します。

ミューテーションテスト：テストが実際に機能することを証明する

ミューテーションテストは、テストの失敗感度を検証するための体系的なアプローチです。このプロセスでは、アプリケーションコードに意図的なバグ（ミューテーション）を導入し、いずれかのテストが失敗するかどうかを確認します。ミューテーションが存在しているにもかかわらずどのテストも失敗しない場合、そのミューテーションは「生き残った」とみなされます。これは、そのコードパスにテストスイートのカバレッジギャップがあることを意味します。

高いミューテーションスコア（少なくとも1つのテストによってキルされたミューテーションの割合）は、テストスイートが実際のリグレッションを検知する能力と強く相関しています。ラインカバレッジとあわせてミューテーションカバレッジを追跡するチームは、ラインカバレッジのみを追跡するチームよりも、欠陥検出率が意味のある形で高くなります。

失敗を念頭に置いたテストの書き方

テストの失敗感度を向上させる上で最も実践的な習慣は、アサーションを確定させる前に「このテストが間違っていたらどうやって気づくか？」と問いかけることです。

「テストを注意深く読まないと、誤った対象に対してアサーションを行っていることに気づけない」という答えが返ってくるなら、そのアサーションは暗黙的すぎます。明示的なアサーション——正確な期待値、正確な期待エラーメッセージ、正確な期待レコード数に対するアサーション——は、論理を追いやすく、誤って空虚な真を生み出しにくいものです。

TestSprite の AI エージェントは、テスト説明の意図に基づいてアサーションを生成します。これにより、時間的プレッシャーの下でエンジニアが手動で書くよりも、具体性の高いアサーションが生成される傾向があります。エージェントは、意図した動作と緩やかに相関するだけの代替指標ではなく、説明に記載されたこと——正確なメッセージ、正確な状態変化、正確なナビゲーション——をテストします。