なぜ UnitTest が必要か

以前、2種類の品質、製品品質とコード品質について対比した。
また FunctionalTest と UnitTest についても違いを比べた。

前回は、製品品質の保証のためには、FunctionalTest が必要であることを説明したが、それらを踏まえて、今回は UnitTest の必要性とは何かを、考えてみる。

=＝＝＝
UnitTest を書く理由、得られる効用について考えると、テストって語が含まれてるぐらいだから、品質向上のためじゃなかろうかと最初は思う。

でも違う。仕様通りに動くかどうかといった製品品質（外部品質）の検証なら、前回書いたように、UnitTest ではなく FunctionalTest の出番になる。また製品品質ではなくソースコード品質（内部品質）の検証だとしても、静的チェックツールがふさわしい。どちらの意味の品質についても、UnitTest の出番ではない。

品質じゃないとしたら、何だろう。UnitTest といえば、自動化テストなわけだから、つまり生産性向上？

うん、生産性の向上である事は間違ってなさそうだけど、でも何の生産性か。ソフトウェア開発にはいろんな作業が含まれるが・・・

ならば、直訳で「単体テスト」だから、単体テストの生産性の向上？

うーん、いわゆる「単体テスト」、つまり旧来のウォーターフォール・モデルで言うような、「一個のモジュールが、後工程の結合テストを実施するに足る品質を満たしているかどうか検証する作業」という意味なら、やっぱり違ってるだろう。

「単体→結合」の観点で見た場合に、そこで単体に要求されている品質は、単体レベルの機能要求がブラックボックス的にで満たされていればそれで良い訳で、これを検証するのは FunctionalTest という事になる。繰り返しになるが、UnitTest は品質（機能・非機能要求の充足）、つまり"doing the right things"は検証しない。

単体テストじゃないし、設計でもなさそうだし、そんじゃ、コーディングの生産性か・・・

まあ、結局そういうことになる。

がしかし、そもそもテストを書くという追加作業をしてるのに、生産性が上がるのはなぜだろう。それにコーディングといってもいろいろあるし、どの局面の何のコーディングだろう。

====
長くなったので、次に続く。