レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

11章プラクティス7テストでふるまいを明示する

テストはすぐにフィードバックを返してくれるので、変更がシステムのほかの部分に悪影響を及ぼしてもすぐわかる。悪影響を及ぼしたら、単に変更を取り消せばよいのだ。難しく考えない。ユニットテストを使ってコード単体ごとに独立した検証を行うことで、ロジックの問題もすぐ解消できる。どんなに見つけにくいバグでも、夜遅くにデバッガーとにらめっこしなくてもよい。ユニットテストでキャッチできれば、コードに入り込まない。そうすれば、あとで見つけて削除する必要もない。

開発者は、フィードバックによって動くものと動かないものがすぐわかる。これはソフトウェア開発の原動力を大きく変えるものだ。すばやいフィードバックがあればテストによって間違いが発見されるので、ものごとの理解も早くなるし、実験も積極的にできる。すばやいフィードバックを得るための簡単な仕組みさえあれば、チームの開発者全員がそれを活用できるし、より良いシステムを作るための学習ツールとして使うこともできる。確かに、良いコーディングプラクティスを学ぶことは、大幅な時間の節約になるだろう。だが、自ら書いたテストからのフィードバックをもとに、良いコーディングプラクティスを見つけていける開発者はたくさんいるに違いない。

私が以前手に入れた中古車は掘り出し物だったが、電気系統にちょっと問題を抱えていた。3人の異なる整備士に修理を依頼したものの、誰も問題の原因を見つけることができなかった。ヘッドライトも消えたままだし、ウインカーも点灯しない。3人ともヘッドライトを交換したが、ウインカーが点灯したのはほんの一瞬だった。だが、4人目の整備士が問題を発見した。問題は1箇所ではなく、2箇所あったのだ。

ウインカーの回路は2箇所で短絡していた。だから3人の整備士が原因を発見できなかったのだ。このような、相互作用する複数の問題によって引き起こされる複合的な問題は、ソフトウェアであれば見つけることはほぼ不可能だ。そのような障害が起きると（実際に起きる）、問題を見つけて解決するのに何時間もかかる。何日もかかることもある。 ...