TDD（テスト駆動開発）

TDD（Test-Driven Development）は開発の進め方の一つです。小さな要件に対してまずテストを書き、まだ実装していない動作が原因で失敗することを確認します。次に、そのテストを通すために必要な最小限のコードを書き、最後にコードを整理します。テストは期待する動作を明確にし、次の実装を導く役割を持ちます。

レッド・グリーン・リファクタリング

1. レッド：要件を検証できる一つの動作に分け、テストを書いて実行し、想定どおりに失敗することを確認します。
2. グリーン：その動作だけを実装し、テストが通るまで実行します。
3. リファクタリング：テストが通る状態を保ちながら、命名や構造を改善したり、重複したコードを整理したりします。その後、次の動作を選んで同じサイクルを繰り返します。

Javaの例

プロジェクトに JUnit Jupiter が導入されているとします。Calculator.add を実装するために、まずテストを書きます。

import static org.junit.jupiter.api.Assertions.assertEquals;
import org.junit.jupiter.api.Test;

class CalculatorTest {
    @Test
    void addsTwoNumbers() {
        assertEquals(5, new Calculator().add(2, 3));
    }
}

最初は add が 0 を返すように実装します。テストを実行すると「期待値は 5、実際の値は 0」という結果になり、失敗します（レッド）。次に、テストを通すための最小限の実装に変更します。

class Calculator {
    int add(int a, int b) {
        return a + b;
    }
}

もう一度テストを実行すると、成功します（グリーン）。この例は小さいため、無理にリファクタリングする必要はありません。続けて 0 や負の数などのケースをテストに追加し、一度に一つずつ動作を実装していきます。

活用方法と注意点

• 要件を検証できる小さな動作に分けると、インターフェースと期待する結果が明確になります。テストを継続して実行することで、既存の動作が壊れた場合も早く気付けます。
• テストでは内部の実装方法を固定するのではなく、外から見える動作を検証します。そうすることでリファクタリングしやすくなります。
• 要件の分割とテストの維持には時間がかかります。また、テストが通っても、確認できるのはテストで扱ったケースだけであり、見落としや不具合がないことまでは保証できません。