インターフェーステスト

モジュールの内部実装ではなく、公開インターフェースに対して振る舞いを検証するテスト手法。「実装詳細に結合しないテスト」とも言われる。

対比：実装詳細テスト vs インターフェーステスト

テストの種類	対象	リファクタリング耐性
実装詳細テスト	内部の実装関数・クラス	低い（内部構造変更で壊れる）
インターフェーステスト	公開インターフェース（API、関数シグネチャ）	高い（外部契約が同じなら壊れない）

テストが頻繁に壊れるのは「テストという手法の限界」ではなく、テストの書き方の問題。内部実装でなくインターフェースに対してテストすれば、内部のリファクタリングでは壊れない。

「インターフェースに対してテストする」原則は、すべての粒度で適用できる。

この構造がすべてのスケールで繰り返される（フラクタル的）。

ContractはStructureとBehaviorの両面から構成される。

インターフェーステストはContractのBehavior側の保証手段。型で表現しきれない実行時の制約（「在庫がある商品のみ注文可能」など）を、境界のインターフェースで検証する。

単体・統合レベルのインターフェーステストが「単一の境界に対する契約の検証」であるのに対し、E2Eテストは複数のモジュールを跨いだユーザージャーニー全体を検証する。「境界に対して振る舞いを検証する」点では共通するが、目的と技術的セットアップが異なる。

AIが生成するコードのガードレールとして、実装詳細に結合したユニットテストよりインターフェーステストが適している：