電子商取引プラットフォームを考えてみましょう。このプラットフォームには、ユーザー認(rèn)証、製品カタログ、注文処理のためのさまざまなサービスがあります。これらのサービスは API を通じて通信します。たとえば、注文処理サービスはカタログ サービスから製品の詳細(xì)を取得する必要があります。

契約テストでは、これらのサービス間の合意 (注文サービスが製品カタログ サービスからどのようなデータを期待するかを指定する) が一貫していることを確認(rèn)します。

契約テストとは何ですか?

コントラクト テストでは、マイクロサービス アーキテクチャ內(nèi)のさまざまなサービス間の通信が合意された仕様に準(zhǔn)拠していることを確認(rèn)します。コンシューマ (別のサービスを呼び出すサービス) とプロバイダ (呼び出されるサービス) の間の対話が、事前定義された「契約」に従っていることを検証します。

この契約は、API またはサービスの入力と出力を定義し、両當(dāng)事者がデータ形式、タイプ、応答構(gòu)造を理解し、合意することを保証します。

これは、開発プロセスの早い段階で不一致を検出し、統(tǒng)合の問題を軽減し、あるサービスの変更によって別のサービスの機(jī)能が誤って損なわれないようにするのに役立つ正式な契約であると想像してください。

契約テストを使用するのはどのような場合ですか?

1. マイクロサービス アーキテクチャ: マイクロサービス環(huán)境では、複數(shù)のサービスが相互に対話します。サービスが別のサービスの API に依存している場合、コントラクト テストにより、予期されるデータ形式と構(gòu)造が一貫性を保っていることが確認(rèn)されます。

2. API 開発: API を開発または更新する場合、契約テストを?qū)g裝することで、チームは 1 つのサービスの変更によって依存サービスとの統(tǒng)合が損なわれないことを検証できます。

3. サードパーティ統(tǒng)合: アプリケーションが外部サービスまたは API と統(tǒng)合されている場合、契約テストは、サードパーティ プロバイダーによる変更によってアプリケーションの機(jī)能が中斷されないことを確認(rèn)するのに役立ちます。

4. チーム間のコラボレーション: 異なるチームが相互接続されたサービスに取り組む場合、契約テストは API 仕様に関する明確なコミュニケーションと期待を維持するのに役立ち、誤解の可能性を減らします。

契約テストを使用する理由

1. 問題の早期検出: 契約テストにより、チームは開発サイクルの早い段階で統(tǒng)合の問題を特定して解決できるため、時(shí)間を節(jié)約し、後期デバッグに関連するコストを削減できます。

2. 信頼性の向上: コンシューマーとプロデューサーの両方が合意された契約を遵守していることを検証することで、契約テストによりサービス インタラクションの信頼性が向上し、アプリケーションの安定性が向上します。

3. 開発サイクルの高速化: 契約テストにより、チームはそれぞれのサービスに獨(dú)立して取り組むことができ、継続的な統(tǒng)合チェックを必要とせずに、開発および展開サイクルの短縮につながります。

4. 破壊的な変更のリスクの軽減: ほとんどの場合、破壊的な変更に対するセーフティ ネットとして機(jī)能し、あるサービスの更新によって別のサービスの機(jī)能が誤って中斷されないようにすることができます。

5. ドキュメントと明確さ: コントラクトは、API 対話に対する期待を概説する生きたドキュメントの形式として機(jī)能し、開発者がサービスの通信方法を理解しやすくなります。

さまざまな種類の契約テスト

コントラクト テストはいくつかのタイプに分類でき、主にマイクロサービス アーキテクチャ內(nèi)のサービス間の対話と API 開発に焦點(diǎn)を當(dāng)てます。ここでは、特にこれら 2 つのコンテキストでコントラクト テストがどのように適用されるかを見ていきます。

1. マイクロサービス主導(dǎo)の場合: マイクロサービス環(huán)境では、消費(fèi)者主導(dǎo)の契約テストが非常に重要です。このアプローチは消費(fèi)者の視點(diǎn)に焦點(diǎn)を當(dāng)てており、消費(fèi)者サービスがプロデューサー サービスとどのように対話するかについての期待を定義します。

   たとえば、支払いサービスがユーザー認(rèn)証サービスに依存する場合、支払いサービスはコントラクトで必要な要求パラメータと予期される応答形式を指定します。これにより、認(rèn)証サービスによって行われた変更によって支払いサービスの機(jī)能が損なわれないことが保証されます。

2. API ドリブンの場合: API 開発のコンテキストでは、プロバイダー契約のテストにより、プロデューサー サービスがコンシューマーによって定義された契約に準(zhǔn)拠しているかどうかが確認(rèn)されます。このタイプのテストは、API が指定どおりにリクエストに正しく応答することを検証するために不可欠です。

   

   たとえば の場合、製品カタログ サービスが製品の詳細(xì)を取得するための API を提供する場合、プロバイダー契約のテストでは、サービスが期待されるデータ構(gòu)造と値を一貫して返すかどうかを検証します。契約に基づいてテストを?qū)g行することで、開発者は自信を持って API の更新や機(jī)能拡張を行うことができ、API に依存する消費(fèi)者サービスを誤って中斷することがないことがわかります。

契約テストを?qū)g行するためのツール

協(xié)定:

• 概要: Pact は、特に消費(fèi)者主導(dǎo)の契約テストで最も広く使用されている契約テスト フレームワークの 1 つです。

• 機(jī)能: 複數(shù)のプログラミング言語をサポートし、コンシューマー サービスでコントラクトを定義でき、プロバイダー サービスによって検証されます

• ユースケース: さまざまな環(huán)境で消費(fèi)者主導(dǎo)の契約テストの実裝を検討しているチームに最適です。

ケプロイ

• 

  概要: Keploy は、契約テストを自動(dòng)的に生成および実行することで契約テストを簡素化し、手作業(yè)の労力を大幅に削減し、エラーを最小限に抑える、市場の新しいテスト ツールです。

• 機(jī)能: ユーザーは、API インタラクションを記録し、再利用可能なテスト ケースを生成することで、テストを簡単に作成できます。これらのやり取りが契約の基礎(chǔ)となります。次に、テストを個(gè)別に実行することでコントラクトを検証し、実際のサービスの依存関係を?qū)g行することなく、API の対話がコントラクトによって設(shè)定された期待を満たしていることを確認(rèn)します。

• ユースケース: API テストの効率と信頼性を強(qiáng)化し、品質(zhì)を犠牲にすることなく開発サイクルを短縮したいと考えているチームに最適です。

春のクラウド契約:

• 概要: Spring エコシステムの一部である Spring Cloud Contract は、消費(fèi)者とプロバイダーの両方の契約テストに役立ちます。

• 機(jī)能: Groovy DSL または YAML を使用してコントラクトを作成し、両側(cè)のテストを自動(dòng)的に生成できます。

• ユースケース: Spring 開発ライフサイクルにシームレスに統(tǒng)合されるため、すでに Spring Boot を使用しているチームに最適です。

郵便配達(dá)員:

• 概要: Postman は、専用ツールのような本格的なコントラクト テストは提供しませんが、スキーマ検証と自動(dòng)テスト スクリプトを通じて、API が事前定義された仕様に準(zhǔn)拠していることを確認(rèn)するのに役立ちます。

• 機(jī)能: OpenAPI 仕様を使用して API スキーマを作成および検証し、テストを?qū)g行してこれらの契約への準(zhǔn)拠を確認(rèn)できます。

• ユースケース: 手動(dòng)テストと並行して API 開発ワークフローに契約テストを組み込みたいと考えているチームに役立ちます。

契約テストの長所と短所

結(jié)論

マイクロサービス アーキテクチャではコントラクト テストが不可欠であり、消費(fèi)者サービスとプロバイダー サービス間の明確な通信を確保します。サービスが API を介して通信する方法に焦點(diǎn)を當(dāng)てることで、問題を早期に発見し、あるサービスが別のサービスを誤って破壊することを防ぎます。コントラクト テストはエンドツーエンド テストに代わるものではありませんが、サービス間の特定の対話に焦點(diǎn)を絞ることで補(bǔ)完します。

テスト戦略の一部として使用すると、統(tǒng)合の問題を大幅に軽減し、コードをスムーズに実行し続けることができます。

よくある質(zhì)問

契約テストを使用する利點(diǎn)は何ですか?

利點(diǎn)としては、問題の早期検出、信頼性の向上、開発サイクルの短縮、破壊的変更のリスクの軽減、API の期待事項(xiàng)の明確な文書化が挙げられます。

契約テストの制限は何ですか?

制限には、セットアップとメンテナンスの複雑さ、チーム間の調(diào)整の必要性、統(tǒng)合問題の対応範(fàn)囲に潛在的なギャップ、契約の継続的な更新の必要性などが含まれます。

契約テストはエンドツーエンド テストの代わりに使用できますか?

いいえ、契約テストでは広範(fàn)なエンドツーエンド テストの必要性が軽減されますが、包括的な適用範(fàn)囲と信頼性を確保するには、他のテスト方法と組み合わせて使用??する必要があります。

契約テストは CI/CD パイプラインにどのように適合しますか?

コントラクトのテストを CI/CD パイプラインに統(tǒng)合して、ビルド プロセス中にコントラクトを自動(dòng)的に検証し、コード変更が行われてもサービスの互換性と機(jī)能が維持されることを保証できます。

以上が契約テストとは: 知識(shí)ガイドの詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國語 Web サイトの他の関連記事を參照してください。