概要
AI時代のユニットテストを「仕様の確認」と「実装の確認」の2レイヤーに分離し、保守性とリファクタリング耐性を向上させる設計手法の提案。
詳細内容
AIによるコード生成が普及し、開発速度と検証の必要性が高まる中で、ユニットテストの役割を再定義する必要がある。本記事では、テストを「仕様の確認（不変の要求事項）」と「実装の確認（開発時の足場）」の2つのレイヤーに明確に分けることを提唱している。
1. **仕様の確認のためのテスト**: パブリックインターフェースを対象とし、実装前に作成。内部構造の変化に影響されず、CIで厳格に管理されるべき「壊れないテスト」である。
2. **実装の確認のためのテスト**: プライベートメソッドや内部ロジックを対象とし、実装と並行して作成。リファクタリング時には書き換えや削除を許容し、恒久的な保守を前提としない。
これらを物理的なディレクトリ（tests/spec vs tests/impl）や命名規則で分離することで、テストが失敗した際の原因（仕様違反か内部変更か）を明確にし、テストコードがリファクタリングの足枷になる問題を解決するアプローチを解説している。