最新のマイクロサービス アーキテクチャでは、アプリケーションは多くの場合 API を介したサービス間通信に大きく依存しています。これらの API が開発中および変更後も期待どおりに動作し続けることを確認することが重要です。これを達成するための効果的な方法の 1 つは、消費者主導契約テスト (CDCT) を使用することです。 CDCT は、サービス (プロデューサー) が、API を使用するサービス (コンシューマー) によって設定された期待に従うことを保証する方法です。

このガイドでは、CDCT とは何か、その仕組み、信頼性の高いマイクロサービス インタラクションを確保する上での重要性、Pact などのツールを使用して CDCT を実装する方法について説明します。

消費者主導の契約テストとは何ですか?
Consumer-Driven Contract Testing は、分散アーキテクチャ内のサービス間の通信が合意された契約に準拠していることを保証するテスト戦略です。従来の API テストとは異なり、API 自体が正しく機能することを確認するだけではなく、消費者のニーズに焦点を当てています。 API コンシューマとプロバイダ間の契約はコンシューマの期待によって定義され、この契約はプロバイダの実装に対して検証されます。

重要な用語:
• Consumer: API を使用するサービス。
• プロバイダー (Producer): API を提供するサービス。
• 契約: 期待される API 動作を指定する、コンシューマとプロバイダ間の正式な合意。

仕組みは?

1. コンシューマはコントラクトを定義します: コンシューマは、プロバイダの API がどのように動作するかについての期待を定義します (例: どのエンドポイント、データ形式、応答ステータス コードを期待するかなど)。
2. 契約は共有されています: 消費者はこの契約をプロバイダーと共有します。この契約は、プロバイダーが満たさなければならない内容の仕様として機能します。
3. プロバイダーは契約を検証します: プロバイダーは、消費者の契約に対して自身をテストし、それが消費者の期待を満たしていることを確認します。
4. 継続的フィードバック ループ: プロバイダーはすべてのコンシューマの契約に対して検証する必要があるため、プロバイダーの API に対する重大な変更は早期に検出されます。これにより、プロバイダーの変更が消費者に悪影響を及ぼさないようにするためのセーフティ ネットが構築されます。

消費者主導の契約テストの重要性
分散アーキテクチャでは、特にマイクロサービスでは、サービス間の依存関係の管理がより複雑になります。 CDCT は、いくつかの方法でこの複雑さを軽減するのに役立ちます:

1.本番環境での破損を防止
消費者は何が必要かを定義するため、消費者の期待を満たさないプロバイダーの API への変更は開発パイプラインの早い段階で検出されます。これにより、互換性のない変更によって実稼働システムが破壊されるリスクが軽減されます。

2.デカップリング開発
消費者主導の契約テストにより、消費者とプロバイダーは独立して開発できます。これは、チームやサービスが個別に進化する場合に特に便利です。コントラクトは、開発サイクルごとに完全な統合テストを必要とせずに、統合が期待どおりに機能することを保証するインターフェイスとして機能します。

3.開発サイクルの短縮
CDCT を使用すると、コンシューマとプロバイダの両方を並行して開発およびテストできるため、開発が迅速化されます。プロバイダーは、消費者がその機能を完全に実装する前でも、消費者の契約に対してテストできます。

4.契約違反の早期発見
契約に違反するプロバイダーへの変更は開発プロセスの早い段階で検出されるため、開発者は問題が重大になる前に対処できます。

消費者主導の契約テストを実装する方法
CDCT の実装にはいくつかのツールが利用できますが、Pact は最も人気のあるツールの 1 つです。 Pact により、消費者は契約を定義し、プロバイダーはそれを検証できるようになります。

Pact を使用して CDCT を実装するためのステップバイステップ ガイドは次のとおりです:
ステップ 1: 消費者の期待を定義する
まず、コンシューマ サービスでコントラクトを定義します。通常、これには次のものが含まれます:
• コンシューマが呼び出すエンドポイント。
• リクエストメソッド (GET、POST、PUT など)。
• 予期されるリクエスト本文またはパラメータ。
• 予期される応答本文とステータス コード。
JavaScript:
で Pact を使用してコンシューマ テストでコントラクトを定義する例を次に示します。

const { Pact } = require('@pact-foundation/pact');
const path = require('path');

const provider = new Pact({
    consumer: 'UserService',
    provider: 'UserAPI',
    port: 1234,
    log: path.resolve(process.cwd(), 'logs', 'pact.log'),
    dir: path.resolve(process.cwd(), 'pacts'),
});

describe('Pact Consumer Test', () => {
    beforeAll(() => provider.setup());

    afterAll(() => provider.finalize());

    it('should receive user details from the API', async () => {
        // Define the expected interaction
        await provider.addInteraction({
            state: 'user exists',
            uponReceiving: 'a request for user details',
            withRequest: {
                method: 'GET',
                path: '/users/1',
                headers: {
                    Accept: 'application/json',
                },
            },
            willRespondWith: {
                status: 200,
                headers: {
                    'Content-Type': 'application/json',
                },
                body: {
                    id: 1,
                    name: 'John Doe',
                },
            },
        });

        // Make the actual request and test
        const response = await getUserDetails(1);
        expect(response).toEqual({ id: 1, name: 'John Doe' });
    });
});

この例では、コンシューマ (UserService) は、/users/1 に GET リクエストを行うときにプロバイダ (UserAPI) がユーザーの詳細を返すことを期待しています。

ステップ 2: 契約を発行する
消費者テストに合格すると、Pact はプロバイダーと共有できる契約ファイル (Pact ファイル) を生成します。この契約は、プロバイダーが検証に使用できるように、Pact ブローカーまたはバージョン管理システムに保存できます。

ステップ 3: プロバイダーが契約を確認する
プロバイダーは契約を取得し、それが消費者の期待に準拠していることを確認します。これは、プロバイダー側​​で Pact テストを実行することによって行われます。 Java で Pact コントラクトを検証する例を次に示します:

public class ProviderTest {

    @Test
    public void testProviderAgainstPact() {
        PactVerificationResult result = new PactVerifier()
            .verifyProvider("UserAPI", "pacts/UserService-UserAPI.json");

        assertThat(result, instanceOf(PactVerificationResult.Ok.class));
    }
}

プロバイダーは、消費者が指定した契約に準拠していることを確認するためにこのテストを実行します。

ステップ 4: 継続的インテグレーション
CDCT が CI/CD パイプラインに統合されると、契約が変更されるたびに、プロバイダーが自動的に契約を検証できるようになります。これにより、API の変更が消費者の期待を裏切らないことが保証され、両方のチームにセーフティ ネットが提供されます。

CDCT のベスト プラクティス

1. 小規模で焦点を絞った契約: 契約は小規模で、消費者のニーズのみに焦点を当ててください。これにより、契約の不必要な複雑さが回避され、検証が簡素化されます。
2. 契約のバージョン管理: 契約を常にバージョン管理します。これにより、プロバイダーは同じ契約の複数のバージョンを処理できるようになり、開発のさまざまな段階でさまざまなコンシューマをサポートできるようになります。
3. 独立した展開: CDCT が CI/CD パイプラインの一部であることを確認します。コンシューマーまたはプロバイダーに変更を加える場合は、実稼働環境の破壊を避けるためにコントラクト テストをトリガーする必要があります。
4. Pact Broker を使用する: Pact Broker は、契約を保存し、消費者とプロバイダーの両方が契約を取得できるようにする中央リポジトリです。また、コントラクトのバージョンと依存関係を視覚化するための UI も提供します。

消費者主導の契約テストを使用する場合
CDCT は、次の場合に特に役立ちます。
• 複数のサービスが相互作用するマイクロサービスまたは分散アーキテクチャがある。
• さまざまなサービスに取り組んでいるチームは、頻繁な統合テストを行わずに独立して開発する必要があります。
• API 契約は頻繁に変更される可能性があるため、消費者の期待を裏切らないようにしたいと考えています。
• 開発プロセスの早い段階で契約違反を検出するには、高速なフィードバック ループが必要です。

結論
消費者主導の契約テストは、分散システム内のサービスが変更を破壊することなく効果的に通信することを保証する信頼性の高い方法を提供します。 CDCT は、消費者の期待に焦点を当て、それに対してプロバイダーを検証することで、安定性を確保しながらチームが独立して開発できるように支援します。マイクロサービス、API ベースのアプリケーション、分散システムのいずれを構築している場合でも、CDCT をテスト戦略に組み込むことで、サービスの信頼性とスケーラビリティが向上します。