契約テスト（Contract Testing）

契約テストは、2 つのサービス間の取り決めを単独で検証します。それぞれの側は、相手のサービスを実際に動かしてテストするのではなく、やり取りを記述した共有の定義、つまり契約（コントラクト）に対してテストされます。コンシューマーが依存しているフィールド名をプロバイダーが変更すると、何かがデプロイされる前に、プロバイダー自身のパイプラインで契約テストが失敗します。コストと信頼性の点で、結合テストと E2E テストの中間に位置します。

コンシューマー駆動契約テストの仕組み

最も一般的な形式は、Pact というツールで広まったコンシューマー駆動型です。

1. コンシューマーがテストを書きます。 モックのプロバイダーに対して、送信するリクエストと、レスポンスのうち実際に使う部分を記述します。たとえば GET /orders/42 が 200 を返し、数値の id と文字列の status を含む、といった内容です。
2. そのテストを実行すると契約ファイル（「pact」）が生成され、これらのやり取りが記録されます。
3. 契約を共有します。 通常はブローカーサービスを使います。
4. プロバイダーが契約を検証します。 記録された各リクエストを実際の実装に対して再生し、レスポンスが一致するかを確認します。
5. デプロイ前に、 チームはリリースしようとしているバージョンが、その環境にすでにある相手側のバージョンと互換性があるかを確認します。

コンシューマーは自分が使うフィールドだけを列挙するため、プロバイダーはフィールドを追加したり、どのコンシューマーも依存していない部分を自由に変更したりできます。

関連するチェックとの違い

• スキーマ検証は、プロバイダーが公開しているスキーマに対してレスポンスを確認します。プロバイダーが自身のドキュメントと一貫していることは分かりますが、各コンシューマーのニーズを満たし続けているかは分かりません。
• 結合テストは実際のプロバイダーを呼び出します。両方のサービスとその依存先を動かす必要があり、遅く不安定になりがちです。
• E2E テストは一連の流れ全体が動くことを証明しますが、フィールド名の変更を見つける手段としては遅く高コストです。

プロバイダー駆動型の契約は、プロバイダーが OpenAPI 仕様を公開し、コンシューマーがそれに対してテストする方式です。公開 API のように、プロバイダーがすべてのコンシューマーを把握・調整できない場合の代替手段になります。

よくある間違い

• 指定しすぎる。 正確な値やすべてのフィールドをアサートすると、契約が壊れやすい機能テストになってしまいます。型のマッチャーを使い、コンシューマーが読む部分だけを含めます。
• 契約でビジネスロジックをテストする。 契約が確認するのはやり取りの形です。正しさはプロバイダー自身のテストで確認します。
• プロバイダーステートを省略する。 「注文 42 が存在する」という状態は検証時にプロバイダー側で準備しておく必要があります。そうしないと、検証が本来とは違う理由で失敗します。