テスト

テストとは

ソフトウェアテストとは、プログラムが期待した通りに動作するかを検証する活動だ。単に「バグを見つける」ためだけでなく、変更を加えても既存の機能が壊れていないことを保証し、安心してコードを書き換えられる土台をつくる役割を持つ。テストが整っているほど、開発のスピードと品質を両立しやすくなる。

テストのレベル

レベル	対象
単体テスト	関数やクラスなど小さな単位
結合テスト	複数の部品を組み合わせた動作
E2E テスト	ユーザー操作に沿った全体の流れ

下位 (単体) ほど高速で原因を特定しやすく、上位 (E2E) ほど実際の利用に近いが実行コストが高い。原因特定の速さが変わるのは、失敗したときに疑う範囲が違うからだ。単体テストが赤くなればその関数を読めば済むが、E2E テストが赤くなった時点で分かるのは「どこかが壊れている」ことだけで、切り分けからやり直しになる。

混同されやすいが、レベルと目的は別の軸だ。単体・結合・E2E は「どの粒度を対象にするか」の区分で、回帰テスト・スモークテスト・受入テスト・性能テストは「何を確かめたいか」による呼び名にすぎない。回帰テストは単体でも E2E でも成立するし、スモークテストはデプロイ直後に最小限の疎通だけを見る使い方を指す。この 2 軸を分けておかないと、「E2E テストと回帰テストはどちらを書くべきか」のような噛み合わない議論に時間を使うことになる。

自動テストの価値

手作業の確認は、人が増えるほど・機能が増えるほど現実的でなくなる。コードで書いた自動テストは、変更のたびに何度でも瞬時に再実行でき、デグレード (以前動いていた機能が壊れること) を即座に検知する。継続的に開発を続けるプロジェクトでは、自動テストの整備が長期的な開発速度を決定づける。

陥りやすい誤解

「カバレッジ (テストが網羅したコードの割合) が高い = 品質が高い」とは限らない。よく使われる行カバレッジが数えているのは「その行を通ったか」だけで、通った結果が正しいかは見ていない。極端に言えば、検証 (アサーション) を 1 つも書かずに関数を呼ぶだけのテストでも数値は上がる。重要なのは、壊れたら困る振る舞いを確実に検証することだ。

もう一つの落とし穴は、実行するたびに結果が変わるテストを放置することだ。原因はたいてい現在時刻・乱数・実行順序・並行処理・外部サービスへの通信に依存していることで、こうしたテストが数本混ざると「また失敗しているが、たぶんいつものやつだ」という空気が生まれ、本物の失敗も見過ごされる。テストの価値は本数ではなく、赤くなったときに全員が手を止めるかどうかで決まる。原因を潰せないなら、依存する時刻や外部通信を差し替えて安定させるか、その 1 本を切り離す判断が必要になる。

また、テストを書く手間を嫌って後回しにすると、変更が怖くなり開発が停滞する。テストは品質保証であると同時に、変更を恐れず前進するための投資だと捉えたい。

考え方を学ぶには関連書籍が役立つ。