第41回: テスト駆動開発（TDD）入門 — 「テストを先に書く」で設計が自然に整う

章: 第5章: テストと品質管理

実装してからテストを書こうとして、後回しになっていませんか？

実装後のテストは「動いているコードを確認する作業」になりがちで、設計の改善には繋がりにくいです。TDDではテストを先に書くことで「何を作るか」が明確になり、余分な実装が増えにくくなります。

実装後にテストを追加する方法の問題点

実装が完了してからテストを書くと、既存のコード構造に引きずられたテストになります。テスタブルでない設計でも「一応動く」ため、依存が複雑なままリリースされることがあります。TDDのRed→Green→Refactorサイクルは設計を継続的に改善する仕組みです。

TDDサイクルと従来開発の比較

チェックポイント: TDDのRedフェーズでは「コンパイルエラーを出すためのテスト」は書きません。テスト対象クラスが存在しない状態でテストを書き、意図的に失敗させてから実装に入りましょう。Greenフェーズでは「テストを通す最小限の実装」を心がけ、綺麗にするのはRefactorフェーズです。

コードサンプル

<?php
// ステップ1: まずテストを書く（Redフェーズ）
public function test_it_calculates_total_with_tax(): void {
    $cart = new Cart();
    $cart->add(new Item('本', 1000));
    $this->assertSame(1100, $cart->totalWithTax(0.1));
}
// ステップ2: 最小限の実装でテストを通す（Greenフェーズ）
// ステップ3: リファクタリングしてコードを整える（Refactorフェーズ）
// Red -> Green -> Refactor のサイクルを繰り返していきます

まとめ & 次のステップ

• TDDのRed→Green→Refactorサイクルを繰り返すことで、設計が継続的に改善されます
• Redフェーズで「何を作るか」を明確にしてから実装に入りましょう
• Greenフェーズでは「テストを通す最小限の実装」を意識してください
• Refactorフェーズで重複排除・命名改善・責務分離を行いましょう
• 最初は小さな関数から始めて、TDDのリズムに慣れることが大切です

次回は FeatureテストとUnitテストの使い分け を学びます。テストを目的に合わせて使い分けて、保守しやすい構成を整えましょう。