http://martinfowler.com/bliki/TestCancer.html

2007/12/6

本の執筆に専念するようになってから、ソフトウェア開発の現場と疎遠になるのがよく心配になる。これまでに現場を離れた有名人を何人も目にしているが、私は彼らと同じような運命をたどりたくはない。私にはThoughtWorksという最高の情報源があるので、まだ地に足をつけていられるのだ。

ThoughtWorksはまた、現場からのアイデアの源でもある。同僚が発見し開発したものについて書くことは楽しい。本当に役に立つものなので、読者のみなさんには是非とも使ってもらいたい。さて、本日の話題は、あまり気持ちのいいものではない。答えの出ていない問題についてである。

話はこうだ。我々はプロジェクトを成し遂げ、ピッカピカのソフトウェアをクライアントに納品した。納品時には自動テスト一式も含めるのが習慣となっており（テストコードと機能コードの行数はだいたい同じ）、テストには、ユニットテスト、機能テスト、受け入れテストが含まれている。いずれの場合も、テストには、ソフトウェアが何を行っているかを明らかにする役割と、ソフトウェアを開発する上で問題を迅速に発見するバグ発見器としての役割がある。我々はこうしたテストを大切に扱っている。テストはソフトウェアシステム構築における成功の鍵なのだ。

数ヵ月後、その幸運なクライアントは、我々に追加作業を依頼してきた。そのシステムに新しい機能を追加したのだという。我々はコードに何か問題があるのではないかと考えたが、問題があったのは我々のほうだった。

テストが、動かないのだ。

テストが動かないというのは、ビルドスクリプトからテストが外されて何ヶ月も実行されない場合や、実行はされるがほとんどがコメントアウトされていたりする場合がある。いずれにしても、我々の大切なテストが癌に冒されているのである。ただただ時間を浪費させ、取り除くのが難しい、あのおぞましい癌にだ。

我々はクライアントに何があったのかを尋ねた。すると彼らは、こう答えた。

”“「変更を加えたら、テストが動かなくなったんで、テストを削除したんだ」

クライアントの開発チームにテストの価値をきちんと伝えきれていなかった我々に非がある。テストが失敗したら無視するんじゃなくて調査すべきだと、きちんと伝えるべきだったのだ。だが、きちんと伝えたところで、テストの癌はよくある病気なのだ。

我々は、テストの癌が表れることによって、テストを書くことに意味が無くなるとは考えていない。我々が去った後に、感染力の強いウィルスが何もかも根こそぎ吹きとってしまうとはいえ、我々がシステムを構築していたときには、まだテストに価値があったのだ。それに、テストが常に癌になるわけではない。近頃、数年前に我々が引き渡したシステムを保守したあとに、TDDに乗り換えた開発者と話をしたのだが、彼によると、テストのある我々のコードは、他の会社のコードよりも扱いやすかったということだ。