ウィッシュリストから実行可能な制約へ：Test First

明確な受け入れ基準がある。次のステップはそれを実行可能にすることだ。

従来の開発において、テスト駆動開発（TDD）の主な動機は設計を導くことだった。テストを先に書き、テストの要件がコードのインターフェースと構造を形作る。Agentの時代では、TDDの動機は根本的に変化する。コーディングコストはゼロに近づく。Agentは数分で完全なモジュール実装を生成できる。コーディングがほぼ無料になると、テストの相対的な価値は無限大に向かう。テストはAgentのアウトプットに対する唯一の客観的な評価手段となる。

Test Firstの具体的な実践は、ビジネスコードの最初の一行が書かれる前に、仕様の受け入れ基準に基づいてテストフレームワークを構築することだ。各受け入れ基準は1つ以上のテストケースにマッピングされる。まだ存在しない依存関係はモックで置き換え、サービス全体から分離した独立したテスト環境を構築する。

その効果は次の通りだ。Agentがコーディングを開始する時点で、既に存在するレッドテストのセットに直面する。Agentの仕事はこれらのテストをグリーンにすることだ。テストが「完了」の定義を決め、Agentのあらゆる変更に対して即座にフィードバックが得られる。

テストは仕様の実行可能な形式である。仕様に書かれた「支払い成功後、請求ページにレコードが表示される」は、テスト内の具体的なアサーションになる。特定のパラメータで支払いインターフェースを呼び出し、データベースに対応するレコードが追加されたことを検証し、インターフェースが期待されるステータスコードを返したことを検証する。曖昧な自然言語が、正確で繰り返し実行可能なチェックに変換される。

これは仕様とテストの間に厳密なマッピング関係があることを意味する。受け入れ基準がテストに変換できない場合、その基準自体をさらに明確化するため仕様段階に差し戻す必要がある。対応する受け入れ基準のないアサーションがテストに含まれている場合、そのアサーションは余分であるか、仕様の漏れを露呈している。両者は同期を保たなければならない。