ホワイトボックステスト（White-Box Testing）

ホワイトボックステストは、コードを読んでテストを設計する手法です。テスター（多くの場合は開発者自身）が分岐、条件、ループ、エラー処理を見て、それらを意図的に実行するテストを書きます。グラスボックステスト、クリアボックステスト、構造テストとも呼ばれます。最も一般的な形はユニットテストで、通常はコードカバレッジで測定されます。

例

String grade(int score) {
    if (score < 0 || score > 100) {
        throw new IllegalArgumentException("score out of range");
    }
    if (score >= 50) {
        return "PASS";
    }
    return "FAIL";
}

コードを読むと、結果が 3 通り（例外、PASS、FAIL）あり、最初の if には、それぞれ単独で例外を引き起こしうる 2 つの条件があることがわかります。構造から選んだテストは次のとおりです。

入力	実行されるパス
-1	score < 0 が真、例外
101	score > 100 が真、例外
50	範囲内、score >= 50 が真、PASS
49	範囲内、score >= 50 が偽、FAIL

これで分岐カバレッジと条件カバレッジが 100% になります。ちょうど 50 と 49 をテストすることで、>= を誤って > と書いてしまったミスも検出できます。

ホワイトボックステストとブラックボックステストの違い

ホワイトボックスは「このコードのすべてのパスが正しく振る舞うか？」を問い、ソースコードが必要です。ブラックボックスは「システムは要件どおりに動作するか？」を問い、仕様だけがあれば足ります。ホワイトボックスは、テストされていないパス、デッドコード、分岐内のロジックの誤りを見つけます。ブラックボックスは、欠けている機能や要件と食い違う振る舞いを見つけます。欠けている機能にはそもそもコードがないため、ホワイトボックスではそれを見ることができません。良いスイートは両方を使います。

限界

• テストがコードの誤りをそのまま写してしまう。 開発者が要件を誤解していた場合、コードから書いたテストはその誤った振る舞いを正しいものとして確認してしまいます。
• 密結合。 private メソッドや内部構造に依存するテストは、振る舞いが変わっていなくてもリファクタリングのたびに壊れます。可能な限り公開インターフェースを通してテストしましょう。
• カバレッジは正しさではない。 すべての分岐を実行したからといって、アサーションに意味があるかどうかは何もわかりません。