テストを書く

http://t-wada.hatenablog.jp/entry/debugging-tests
和田さーん！

テスト駆動開発（TDD : Test Driven Development）は、プログラマが自分の不安を克服し、自分が書くコードに自信を持ちながら一歩一歩進んでいくための手法です。不具合の発生は、端的に言えばこれまでの「自信」を揺らがせる事態です。テスト駆動開発者は不具合にどう立ち向かうのでしょうか？

やはりテストを書いて立ち向かってゆくのです。

チーム内にテストを書く習慣を持ち込んで三年、最初のうちは工数が増えるだけだ（あるある）、テストを書いても不具合がでるじゃないか（あるある）、システムテストでカバーすればいい（あるある）などという抵抗があり、それでも僕は淡々と雨の日も、晴れの日も、雪の日も、朝も夜も深夜も、終電後のオフィスでも、GW中の人気のないオフィスでも、自動テストをかき、そのプラクティスの勉強会をし、Jenkinsを導入し、定着を図ってきた。

三年で、ずいぶんと書いてもらえるようになったと思う。

エンジニアは新しいものが好きだ。新しいものがあれば古いものはすぐに捨てて、そちらに飛びつきたがる。自動テストで毎日定期的にビルドを走らせているのに、静的解析ツールが出たと聞けばそれを試したがり、一度使えることがわかればそのまま忘れ去ってしまう。その横で、僕は単体テストを書き、やがてそれだけでは足りないので社内用単体テストのフレームワークを作り、その使い方のドキュメントを書き、GUI自動テストを導入し、ひとまず上司を納得させるためにそれで長期試験と負荷試験を実施し、そしてそれをCIツールに組み込んでいった。今月の半ばにようやくその長い道のりは終わった。

それでも、不具合は発生する。
そのたびに誰かが口にする。ユニットテストだけではダメなんじゃないか。自動テストではだめなんじゃないか。
そうではないのだ。不具合が発生したのは、テストが書かれていない部分なのだ。テストは常に完全ではなく、また完全になることはない。しかし書き続けていけばやがて不具合が検出される。不具合が検出された場所は、もう二度と不具合の出ない場所だ。なぜなら、不具合が発見されれば、テストコードが書かれるからだ。
もちろん、そのコストとリターンが見合わないということは大いにあるだろう。どこまでを自動化テストの責務とするか、それはその時状況によって決めていくしかない。ステートメントカバレッジ100%にすることが常に正義なわけではない。プロダクトアウトの製品だけを作っているわけではないのだから、ここでは「最低限正常系のテストだけでも」という方針でテストを書くので構わない。1%でも、あるいはたった0.1%の進歩でしかないとしても、ないよりはマシである。それがテストを書くということなのだと思う。