単体テスト
単体テストは、ユニット自体に不確実性を減らすことができボトムアップテストのスタイルのアプローチで使用することができる。最初のプログラムの部分をテストし、その部分の総和をテストすることにより、統合テストは、はるかに容易になる。
精巧に階層化された単体テストは統合テストと等価ではない。周辺ユニットとの統合は、単体テストではなく、統合テストに含まれるべきである。統合テストは、通常、手動で人間によるテストに大きく依存している。高レベルまたはグローバルスコープのテストは自動化が困難であるため、手動テストの方が多くの場合より速く、より安価であると見られている。
それは細部の実装ではなく、実装はプログラマーに任せられている。「動きそうな最もシンプルな事を行なう」慣例に従えば、テストをパスできる最も簡単な解決法は以下のようなものだろう。
ダイアグラム(図)に基づいた他の設計手法とは異なり、単体テストを設計の手段として使用することには重要な利点が1つある。設計文書(単体テストそのもの)を実装が設計に準拠していることを確認するために使用できるのだ。単体テスト設計方法においては、開発者が設計通りに解決策を実装していない場合、テストはパスすることは決してない。
単体テストがダイアグラムのようなアクセシビリティを欠いていることは確かだが、UML 図はこんにち、フリーのツールにより大部分の近代的なプログラミング言語に対して簡単かつ自動的に抽出できるようになっている(通常IDEの拡張機能として利用可能)。xUnitフレームワークに依存するフリーのツールは、人の目で見られるためのグラフィカルレンダリング機能を他のシステムにまかせている。
テスト駆動のアプローチでソフトウェア開発を行う場合、単体テストが正式な設計の代わりになる。各単体テストは、クラス、メソッド、および観測可能な動作を指定する設計要素として見ることができる。次のJavaの例が、この点を説明する助けになる。
ここに実装のいくつかの要素を規定するテストクラスがある。まず Adder というインタフェース、引数のないコンストラクタをもつ実装クラス AdderImpl があるはずである。続いてAdderインタフェースが、2つの引数をとり、整数を返す add というメソッドを有する、ということをこのテストクラスのコードが示している。また、境界値として代表的な値や、小さな範囲の値に対して、表明 (assertion) によってこのメソッドの動作を規定する。もしassert文の条件が満たされなかった場合、AssertionErrorがスローされ、テストプログラムが中断されることでテスト失敗として報告される。
この場合、単体テストは最初に書かれているため、求められる解決策の形と挙動を示す設計ドキュメントの役割を果たす。
パラメータ化された単体テスト(PUT:Parameterized Unit Testing)はパラメータが必要なテストである。通常の単体テストは、閉じたメソッドであるが、PUTはいかなるパラメータも取りうる。PUTはJUnit 4と様々な.NETテストフレームワークによってサポートされてきた。単体テストに適したパラメータは手作業で作成、あるいは、テストフレームワークにより自動生成される場合もある。QuickCheckのようなテスト入力を生成する商用テストツールも多い。