※この記事は、[単体テストを信用するな(1)]の続きです。
(1)を読んでいない人は、先にそちらを読んでください。
大抵のプロジェクトでは、プログラマは「設計書に書かれた日本語」を頼りに実装を進めます。
多くの場合、設計者の意図は正しくプログラマに伝達されるのですが、
設計書に少しでも曖昧な表現が紛れ込んでいた場合、正しく伝達されるとは限りません。
あるいは（酷い言い方ですが）人間は出来るだけ楽な道を進もうとするので、
無意識のうちに、自分の都合のいい解釈をしてしまうこともあるでしょう。
このような場合、プログラマは自分の認識が正しいと信じて疑わないわけですから、
プログラムが設計者の意図と違う動きをしていても、単体テストでは検出できないことになります。
プログラマからしてみれば、「自分の意図した通りに動いている」わけですからね。
単体テストで検出できないバグは、次の結合テスト(IT)で回収することになります。
結合テストの説明はまた次回にしますが、単体テストとの大きな違いは
「テストは設計者が行なう」という点です。
今度は設計者自身がテストするのですから、設計者の意図した通りに動かなければ
すぐにバグを見つけ出すことが出来ます。
さて、私が「単体テストを信用するな」と書いた理由は理解していただけたでしょうか？
結局の所、単体テストだけではバグは取りきれないのです。
さらに言ってしまうと、どの部分が設計者の意図とズレているかなんて分からないのですから、
実質的には「テストは何も済んでいない」のと同じだと言うことです。
そのため結合テストでは、単体テストで一度確認した項目についても、
再度テストを行う必要があります。
…では、単体テストを行うことに意味は無いのでしょうか？いいえ、そんなことはありません。
もし単体テストを行なわなかったら、結合テストでシステムエラーが頻発し、
テストが進まなくなることでしょう。それを予め防ぐことは非常に重要です。
若干酷い言い方かもしれませんが、単体テストとは結合テストを行なうための「地ならし」であり、
システムエラーなどのプログラム的なバグを取り除くことを主眼とすべきなのです。
時々この辺の話が理解できていないSEがいて、
「単体テストで細かいテストは済んでいるから、結合テストでは大まかな動きを見れば良い」
などと言い出す人が居ますが、これは問題アリです。
例えば日付を設定するデータ更新処理で、間違った値が設定されたらどうなるでしょうか？
プログラマが「この値で更新するのが正しい」と思い込んでいたら、単体テストは通ります。
そして、結合テストでは「細かいこと」と一蹴してテストを行わなかったら…。
リリース前に、たまたま誰かが見つけてくれるのを祈るばかりです。
