テストのふたつの意味とTDD

もともとテストにはふたつの意味があると思います。

バグを見つける
バグがないことを示す

前者は、作成中のソフトウェアにはなにがしかのバグが含まれていて、これを取り除くためのテストです。境界値分析やバグ推測に基づいて行うテストは、効率良くバグを見つけることを意図していて、このテストの例と言えるでしょう。

後者は、上記のバグ取りが済んで、バグがない状態になっていることを見えるようにすることだと言えるでしょうか。テストによるカバレージが云々されるのはこの意味でだと考えられます。

前者の意味では、バグを見つけないテストには意味がありません。逆に、後者のテストはバグを見つけないことに意味があります。相反するようですが、テストにはこの両面が求められていると思います。

それにしても、前者のテスト＝バグを見つけるテストは、本質的に難しいと思います。見つけるべきバグは、ソフトウェアにどれだけ含まれているのでしょう。このテストはどれだけ実施したら終わってよいのでしょう。教科書的にはバグがみつからなくなるまで(バグが収束するまで)テストするようなのですが、時間が最重要資源である一般的なプロジェクトにおいてそれはやりにくい。組織の過去実績に基づくバグ検出目標に従うというやり方もありますが、ばらつきが大きいのでそれもいまひとつ。結局一定のカバレージを達成したところでやめるというところなのでしょうか。

そもそも、バグを見つけるテストの存在は、コードにバグが含まれていることを前提にしています。バグが含まれること承知で多量にコードを書いて、後からデバッグする、というモデルが前提になっているということを強調したいです。かつて計算機使用コストが極めて高かった時代はこのモデルしかありえなかったと思われますが、今日には違うモデルも考えられるでしょう。

TDDはこれとは異なるモデルに依っていると考えられます。スコープをできるかぎり小さくすることと、あるべきスペックと照らし合わせることで、バグを即時検出して除去できるようにしています。また、直接の関心の範囲を外れた部分についてはテストセットに保証させます。このTDDのテストはバグを見つけるためのテストではないことはあきらかです。では、TDDは「どの程度」バグがないことを保証するのか？という話になるでしょう。

あー筆が遅くてだめだ＞自分。とりあえず今日はここまでにします。