テスト種別（契約・境界）

マイクロサービスやフロントエンド/バックエンド分離アーキテクチャでは、サービス間のインターフェース（API）が暗黙の契約として機能する。この契約が壊れたとき、E2Eテストが失敗するまで問題が表面化しないことが多い。契約テストはサービス境界に着目し、コンシューマーとプロバイダーの期待値を明示的に記述することで、破壊的変更をより早い段階で検出するアプローチだ。

コンシューマー駆動契約テスト（CDCT）はコンシューマー（呼び出す側）がプロバイダーへの期待（契約）を定義し、それをプロバイダーが検証するモデルだ。PactはCDCTの代表的な実装で、コンシューマー側でモックサーバーを使ってインタラクションを記録したPactファイルを生成し、プロバイダー側でそのPactファイルを使って実際のAPIが期待を満たすかを検証する。PactBrokerはPactファイルを集中管理するサーバーであり、コンシューマーとプロバイダーの依存関係も可視化できる。

OpenAPIスキーマを使ったバリデーションはコントラクトテストの軽量な代替だ。Prismはスキーマに基づいてモックサーバーを起動したりリクエスト/レスポンスを検証したりできる。GraphQLでは@deprecatedディレクティブやgraphql-inspectorによるスキーマ変更の検知が有効だ。どのアプローチでも「破壊的変更を本番反映前に検出する」という目的は共通している。

コードレビューで着目するポイント

• APIのレスポンス構造が変更された際にコンシューマー側のPactが更新されているか
• Pactの契約がコンシューマーの実際の使用パターンを反映しているか（使われないフィールドが多くないか）
• OpenAPIスキーマの変更がバージョニングポリシーに従っているか（Semver）
• GraphQLスキーマに@deprecatedが付けられた後の削除タイムラインが明確か
• 破壊的変更の検出をCIパイプラインに組み込んでいるか
• コンシューマーとプロバイダーの変更が同期してデプロイされるような調整がなされているか

典型的なアンチパターン

プロバイダー主導の契約: プロバイダーが「このAPIを提供する」と一方的に定義し、コンシューマーへの影響を確認しない。コンシューマーの期待がドキュメントに反映されていない部分で破壊的変更が発生する。

契約テストのないマイクロサービス連携: サービス間の統合をE2Eテストのみで担保する。デプロイのたびに全サービスを起動してE2Eを実行するコストがかかり、フィードバックが遅い。

スキーマの形骸化: OpenAPIドキュメントが実装と乖離し、更新されないまま残る。スキーマが信頼できる情報源でなくなり、コンシューマーが手動でAPIを試して仕様を調べる状況になる。

参考リソース

• Pact https://pact.io — コンシューマー駆動契約テストのデファクトスタンダード
• PactFlow https://pactflow.io — PactBrokerのSaaSバージョン
• Prism https://stoplight.io/open-source/prism — OpenAPIベースのモックサーバー・バリデーター
• graphql-inspector https://graphql-inspector.com — GraphQLスキーマ変更の検出ツール
• Schemathesis https://schemathesis.io — OpenAPIスキーマからファジングテストを自動生成