…とか。
…とか。
…とか。
…とか。
…とか。
そもそも範囲の違いだと思っているのが大間違い。これらの対象範囲は包含関係になっていて、単体テスト範囲は全て結合テスト範囲にも含まれる。範囲を絞ったテストのほうが実施コストは低くて、デバッグにつながる情報を集めやすいというのは間違っていないけど、同じことを重ねてテストしてどうするの。
テストの各段階はそれぞれ「何を検証するか」が異なる。
- 単体テストは実装を検証するもので、コードからテスト項目を考える。テスト項目を考えるのは実装をした者ということになる。
- 結合テストは設計を検証するもので、設計書からテスト項目を考える。テスト項目を考えるのは設計をした者ということになる。
- システムテスト(統合テスト/総合テスト)は仕様を検証するもので（略。顧客からの要求を叶えているのか検証するもの。
成果物はすべて検証されるものなので、それぞれに対応したテスト段階があるということ。（そういう観点で考えて、コードと同時に検証される『詳細設計書』*2は成果物に値しない。もっとも、これもコード化する前に自動テストできれば有用にはなるけど）
別の表現をすると単体テストはコードに触れるホワイトボックステストになる。確かに単体テストの対象は1モジュールを越えないけど、それはホワイトボックステストだから。対象範囲を第一に考えていてはいけない。
個人的には単体テストがバグ出しのテストで、それ以降は上流に向かって「テストに通らなければならない」という確認と品質保証の度合いが強まっていくと思う。テスト実施の自動化が進めばより上流で問題が発覚してもよくなるんだろうけど。
なんで「単体テスト」「結合テスト」なんて言うんだろうね。「実装テスト」「設計テスト」のほうが実態に則しているのに。
というわけで、「単体テストはモジュール単位で仕様と実装の整合性を確かめるもの」などと書かれている説明も要領を得ていないことになる。*3これではブラックボックステストの説明だ。ホワイトボックステストが可能なのにブラックボックステストにこだわる意味ってある？
Googleで「単体テストとは」を検索すると、こんなページが上位にくる。これが日本のレベル？
単体テスト（UT）とは - IT用語辞典 e-Words
単体テストとは 「モジュールテスト」 (unit test) たんたいテスト： - IT用語辞典バイナリ
せめて「実装が設計通りであることを確認する」という説明なら間違いではないのに。
