コンシューマー駆動契約テスト とは？

普通のAPIテストは提供側（プロバイダー）が「うちのAPIはこう動きます」と定義してテストする。契約テストは逆で、利用側（コンシューマー）が「うちはこういうレスポンスを期待しています」と先に宣言するんだ。お客さん目線でAPIの仕様を決めるイメージだよ。

プロバイダーが勝手にAPIを変更して、コンシューマーが壊れるのを防ぐためだよ。マイクロサービスが増えると、あるチームがAPIのフィールド名を変えただけで5つのサービスが壊れる…みたいな事故が起きるんだ。

まずコンシューマーチームが「このエンドポイントにGETしたら、nameフィールドとageフィールドが返る」という契約ファイルを書く。次にプロバイダーチームがその契約に対してテストを実行する。契約を満たしていればOK、破っていたらCIが失敗するんだ。

契約テストの代表的なフレームワークだよ。コンシューマー側でPactテストを書くと契約ファイル（Pactファイル）が生成される。それをPact Brokerというサーバーにアップロードして、プロバイダー側が検証する。「can-i-deploy」コマンドで本番デプロイ前に互換性を確認できるんだ。

E2Eテストは全サービスを起動する必要があるから遅いし不安定になりやすい。契約テストはサービスごとに独立して実行できるから速くて安定しているよ。E2Eは最終確認として少数だけ走らせて、連携の検証は契約テストに任せるのが現代的なテスト戦略だね。

マイクロサービスが3つ以上になったら検討すべきだね。2つのうちはまだ管理できるけど、サービスが増えると「誰がどのAPIのどのフィールドを使っているか」が把握できなくなる。その前に契約テストを入れておくと、安心してAPIを進化させられるよ。