開発を急ぐ状況の中で、単体テストを省略していきなり結合テストしたいと思うかもしれない。しかし、単体テストを軽視すると痛い目を見ることは間違いない。少なくとも単体テストを軽視したプロジェクトの中で、私は何度か痛い目をみた。
テスト不十分な状況での実機動作は機器を破壊する
チェックリストを一箇所に集約するために、文章を移動しました。対策編の記事を読むだけで方向性を見出せるようにしたいと思う。
人によって単体テストへの理解が異なる
何かを作り上げたときになってからバグが見つかると、「ソフトウェアを今から直せばいいよ」とならないプロジェクトにかかわってきたため、単体テストをしないことはありえないプロジェクトで仕事をしてきた。
人によっては、単体テストの重要性に気づかないままソフトウェアの開発を進めてくるプロジェクトに関わってきたため、単体テストを後回しにする傾向がある（あるいは分野違いのまま、ソフトウェアを含む開発のプロジェクトマネジャーになって、単体テストの重要性に気づかないままいるのかもしれない。）。そして、単体テストをしないために、プログラムの中でバグが潜んでいる部分について間違った判断をして貴重な工数を無駄にしてしまう。(問題の見極めに失敗して、問題のある方で課題をほったらかしにして、問題のない方に嫌疑をかけてしまう状況を生み出してしまう。その後、きちんとした名誉回復がされないと、該当のモジュールを開発したメンバーの意欲をそぐという組織運営上問題となる自体を引き起こす。)
「単体テストは理想だけど、、、、」
「単体テストは理想だけど、、、、」というひまがあったら、一つでも単体テストを実装してみよう。
単体テストの重要性は、開発テーマ自体にあって、あなたの理解に関係しない。
単体テストの重要性は、開発テーマ自体にあるのだから、あなたが「単体テストは後回し。」としたところで、解決しない。
単体テストを先送りしたツケは、大事な局面での無様な失敗ということになりうる。
単体テストは万能ではないから、単体テストをしても、大事な局面で失敗することはあるだろう。
単体テストが不十分で、それでもバグを見逃すこともあるだろう。
しかし、単体テストを軽視したツケは、必ずやって来る。
単体テストを無視していいのは、あなた個人の趣味のプログラムの範囲の中でだけだ。
アルゴリズムは、多数のデータで期待どおりの動作をすることを検証しておこう
開発したアルゴリズムは、「うまくいく」と自称しているほどにはうまくいかないものだ。入力として想定しているデータの素性と、実際に入ってきたデータの素性が違っていることでうまくいかないことがある。また、想定していた使い方と違った状況で使われることもあり、それもうまくいかない要因を増やす。
うまくいくことを担保するには、多くのデータを使って検証する。多くのデータを検証するには、アプリケーション全体として動作させるのではなく、モジュールとしての動作を多数させることで検証させるのがよい。
開発スケジュールの中に単体テストを必ず入れておくこと
単体テストが自動化テストでできるようになっていれば、ソフトウェアの改訂後の劣化を予防できるし、テストを繰り返す際の工数を無駄に増やすこともない。
単体テストを行うには、一つ一つの関数の意味を明確にしなければならない。
単体テストが記述できるように要件定義すること。
単体テストをするためには、適切な依存性をもった関数になっていなければならない。
単体テストを軽視すると、実装済みでバグがかれているとみられるものと、バグが残っているものとの区別ができない。
成功するプロジェクトと失敗するプロジェクトとを分けるものは、どのように効果的に品質の確保を確かなものにするかという差にあると思う。
追記：
回帰テストをすることで、リファクタリングなどの改造によって動作結果を変えてしまっていないことを確認しよう。
ある時点の動作結果を保存しておき、現行の版の動作結果を出力させ、その比較をする。
そのようなテストは、自動化しやすい。
単体テストは時間を節約する。
- ファイル入力でモジュールをテストすると、実機なしでもテストできる。 実機なしでもテストできることで、そのモジュールのテストができる分だけ、テストが頻繁にできる。
- ファイル入力でテストすることで、再現性のテストが実施できる。
- 単体テストで実行できるので、すぐに目的の箇所のテストができる。
単体テストは問題の発覚を早める。
- 問題は早めに見つけることが大切
- 早めに見つけられれば、早めに対策が可能になる。
- 得体のしれないバグとなる前に、どのモジュールのバグなのかを把握できる。
- テスト駆動開発は、変更とバグの発見と解決の期間が短くなることを述べている。
こういった理由があるから、単体テストをして、仕事の質を向上させましょう。