単体テストあれやこれや

巡回しているブログで、どうやら単体テストについて議論されています。

「単体テストの議論では、世代間のシステム設計法（思考法）の違いを考慮しないと。。」
「独断と偏見の「単体テスト」の解釈：プログラム仕様書の有無で変わる？」
「何故、単体テストを省こうとするのか？」
「バグを求めるものたち（前編）」
「バグを求めるものたち（中編）」
「バグを求めるものたち（後編）」
「意見募集！単体テストって何ですか？」
「単体テストって？パート２」

この単体テストの定義というのは非常に難しいと感じています。いろいろな立場の方から意見を求められると「プロジェクトによって異なりますから」と言ってしまう自分がいます。
学問よりの立場では、単体テストというのは「モジュール」単位のテストということになります。ソフトウェアテストの教科書やソフトウェアエンジニアリングの教科書では、それに近い意味合いのことが書かれています。「ウィリアムのいたずら」さんがSLCPの定義を用いて、ソフトウェアユニット＝プログラムの基本単位≒プログラムと書いていますが、SLCPが書かれた時代背景を考えると、プログラムよりも細かい粒度をさしていると思っています。別の意見では、「単体テストはホワイトボックステストができるレベル」というのもあります。

現場の立場で見てみると、COBOL時代の「モジュールの定義」とオブジェクト指向時代の「モジュールの定義」とがうまくリンクしていないところがあるようです。聞いた話ですが、COBOL時代からの品質管理担当者の意見では、「Javaのメソッドは単体テスト、クラスは結合テスト」なんて言っているところもあります。

また、現場では単体テストが幾つかに階層化されていてモジュール単体、プログラム単体、機能単体なる言葉があったりします。
単体テストにも複数の種類があります。これを「m_pixy」さんは、

１．デバッガなどを使って行単位の動作を見ながらホワイトボックス
２．JUnitなどを使ってメソッド単位で入出力の確認
３．WEBシステムのレイヤーごとにドライバ・スタブを作成して確認
４．サーバを起動して画面の入出力（ブラウザから）

と書いています。
なぜ、現場で単体テストの種類が増えるのかというと、発注元や協力会社との契約が絡んでくるからです。
単体テストとそれ以降の工程とで契約条件を変えるところが多いかと思います。となると、その単体テストの範囲が問題になってきます。

そんなこんなで、きれいな定義ができないのが現状だったりします。業界全体で統一的な見解ができればコミュニケーションロスも少なくなるんですが．．．．