ある程度モジュールが出来上がってきたら，モジュールが提供する機能をテストすることが重要です．主な目的は，バグを検出して修正することです．モジュールを作成した本人が担当すべきテストであり，技法としてはホワイトボックス法などが使われます．

!!! テストの意義

（書籍『経験ゼロでもできるプログラミング現場の単体テスト』より）

* 中規模以上のシステム開発では，設計に時間がかかってテストに時間をかけられないこともある．
* よって，致命的な障害が発生する可能性がある．
* とはいえ，すべてのケースを想定してテストを実施することはできない．
* ゆえに，テストケースを絞る必要がある．
* 各テストフェーズの礎となる'''単体テストが重要'''になる

!! まとめてテストはダメ

* 時間がかかる・問題箇所が切り分けづらい
* モチベーションが下がる
* リスクの先送り
* プロジェクト終盤で行うテストは，再現→原因調査→修正→再テストと，かなり時間がかかるので，'''プロジェクト序盤から実施するべき'''．

!!! テストの考え方

!! 準備するもの

テスト用メインプログラム
* 提供する機能を使う
* うまく機能するかを，プログラム，または人が判断する

テストすべきモジュール

下位モジュール

* テスト済みの下位モジュール
* あるいはその代わりとなる代替インタフェースモジュール

!! テストできること

* 提供機能の不具合
* インタフェースの自然さ

!!! ホワイトボックス法とブラックボックス法

動作チェックのために必要な値を含めたデータのことを「テストデータ」と呼びます．このテストデータを，実際にプログラムをコーディングする「エンジニア側の視点」から作ることを「ホワイトボックス法」，モニュールやシステムを使う「ユーザ側の視点」から作ることを「ブラックボックス法」と呼びます．

!! ホワイトボックス法

プログラムの処理手順や処理内容といった'''内部構造を意識'''して，バグが発見できるようにテストデータを作り込みます．ソースプログラム中の文，分岐，条件などを網羅的に実行してバグを見つけます．

||テスト|内容
||ステートメントカバレッジ(命令網羅)| ソースコードの全命令・文のうち，１回でも実行されたステートメントの割合
||ブランチカバレッジ(分岐網羅)| ソースコードの全分岐のうち，１回でも実行された分岐の割合
||コンディションカバレッジ(条件網羅)|ソースコードの分岐に設定されている１つ１つの条件が成立・不成立の両方が実行されたの割合

!! ブラックボックス法（参考）

プログラムの内部構造をあまり意識せず，「このデータを処理したら，結果としてAという値が返ってこなければならない」といった要件をクリアできるかどうか，を検証するようなテストデータを作るやり方をいいます．モジュールを統合した以降のテストに使われる技法です．

||テスト|内容
||同値分割法|プログラムが期待する「有効同値」及び「無効同値」を入力として結果を確認
||境界値分割法	|プログラムの「有効同値」と「無効同値」の境界となる値を入力して結果を確認