なぜ単体テストを書くのか?

先日、CLR/H カフェ #3 を開催し、前回投稿の jasmine 単体テスト実行環境を構築することをメインテーマに参加者各位が集まった。

その CLR/H カフェ #3 の席にて、「なぜ単体テストを書くのか?」という話が持ち上がった。

このブログ記事では CLR/H カフェ #3 で披露させていただいた持論を採録したいと思う。

単体テストを書く理由

単体テストの効能はあちこちで言及されていると思うので、ここでは割愛する。
単体テストの効能は、それはもう、いろいろと多数挙げられることだろう。

しかし、それらいろいろな理由のどれよりも、自分が単体テストを書く動機として強くあるのは、以下の2つだけだ。

1. コードを変更してもデグレートを起こしにくくなる
2. プログラムがより早く仕上がる場合がある

以下、詳細を記す。

1. コードを変更してもデグレートを起こしにくくなる

多くのソフトウェア製品というものは、多かれ少なかれ、仕様や実装の変更が付きものだと思う（少なくとも自分の経験の上ではそうだった）。

そうしたソースコードの変更が発生する場合に、単体テストが整備されていたらどうだろう。
コードの変更によって、別の機能を壊してしまった場合、単体テストの失敗という形でそれを知ることができる。
よって、何かしらの理由に伴うコード修正にあたって、別の不具合を引き起こす危険はそのぶん低く抑えることができる。

しかし単体テストが備わっていなかったら?
コード修正にともなうほかの不具合を併発する危険度はぐっと上がってしまうことだろう。

また、本当に他の不具合を引き起こすかどうかというだけでなく、コードの修正に対する開発者の姿勢・気持ちにも大きく影響がある。

単体テストがあれば、これから自分の行うコード修正が悪影響を起こす心配をすることなく、たとえ自分がイチから書いたわけではない他のメンバーが書いたコードに立ち向かうときでも、自信をもって積極的なコード修正に取り組むことができるだろう。
何か間違ったことをしでかしたら、単体テストが失敗することでわかるのだから。

しかし単体テストがなければ、ひるんでしまうのが人の気持ちというものではないだろうか。

単体テストがあれば「ボーイスカウトルール」、すなわち「来た時よりも綺麗に」の習慣により、積み重なる仕様変更や実装修正に対しても、プログラム全体は見通しよく適切なアーキテクチャとアルゴリズムで構成され、それが維持されていることだろう。

しかし単体テストがなければ、どうしても「動いているものは変えない」主義に流れざるをえない。
単体テストなしに「ボーイスカウトルール」をやってしまうと、むしろ大惨事であろう。

そういう点では、単体テストがない体制では「動いているものは変えない」主義は正しい選択であると思う。
しかしそのような体制のもとで作られたソフトウェア製品は、積み重なる修正に対し、その構造が健全なまま維持できるかというと甚だ疑問である。
溶岩流アンチパターンの絶好の棲み処となろう。

2. プログラムがより早く仕上がる場合がある

「単体テストコードを書く工数が増えているのに、なぜ早く仕上がる?」と思われる節もあるかもしれないが、難しい話ではない。

とある GUI なソフトウェア製品の開発中、とある機能を実装している際に、その機能を開発者自身が多少なりとも動作点検・試行せずにリリースすることはないだろう。

さらに、その "とある" 機能への入力の組み合わせが、まぁまぁメンドクサイ場合を想定してほしい。

具多的な例示が難しいが、性別・生年月日・配偶者有無、その他いくつかの入力項目を入力したら、それら入力項目の内容に応じて何かの金額計算をする、といったようなフォームを作っていることを想像するといいかもしれない。

このようなときに、単体テストの体制ができあがっていれば、実装作業はサクサク進む。

すなわち、実装コードとテストコードを書いたらテスト実行するだけ。
自分は Visual Studio 上で C# コードでの開発をすることが多いのだが、この場合だと、Ctrl + R, Ctrl + T の2ストロークのキーボードショートカットを叩くだけでテスト実行される。

しかし、単体テストの体制が整ってなければどうだろう。

実装コードを書いたら、GUI 経由で入力項目を手入力し計算結果が仕様どおり正しいか確認する流れとなろう。

ここでネックになるのが "入力項目を手入力" の部分だ。
当たり前だが、このようなメンドクサイフォームに色々な組み合わせを "手入力" するのは結構時間がかかる。

「単体テストコード書いてる時間より、手入力しててもまだ早いんじゃないの？」という場合もあるかもしれない。

しかし普通は、実装コードが一発でひととおりの入力にパスすることは少ないのではないだろうか。

その場合、単体テスト体制があれば、実装コードだけなおしてあとはテスト実行するだけで済む。
しかし単体テスト体制がなければ、"手入力" をまた最初からやり直しである。

ここで実装スピードに圧倒的な差がつくわけである。

これが「単体テストを書いたほうが、プログラムがより早く仕上がる場合がある」という理由だ。

まとめ

以上、自分が単体テストを書く動機についてまとめてみた。

自分は上記2つの理由を背景に、単体テストを "書かされる" のではなく、"書きたくなる" 気質となったと思う。

気持ちよく自信を持ってプログラムの構造改革に取り組めるし、場合によってはかったるい GUI 経由の手入力することなく実装を進められるのだから。

しかしところが、"テストを書きたくなる" と自称しているのとは裏腹に、自分の取り組みの場合、単体テストの網羅度 (カバレッジ) は、実はかなり低いと思う（ちゃんとカバレッジ計測したこともない）。
CLR/H カフェ #3 ではその点にも話が至り、「どのような部分に対して単体テストを書いているのか」「どこまで単体テストを書いているのか」という話題も持ち上がった。

いずれ機会があれば、これら「どんな単体テストを書いているのか?」もここに投稿(白状?)してみたいと思う。