introduction contract testing with examples
この契約契約テストのチュートリアルでは、消費者主導の契約テストとは何か、どのように機能するのか、なぜテスト戦略で使用する必要があるのかについて説明します。
契約テストとは何ですか？
消費者主導のコントラクトテストは、左シフトを真に可能にするAPIテストの形式です。私たちが使用する契約ツールは Pact.io 、これについては、この一連のチュートリアルの後半で学習します。
コントラクトテストは、合格したものをテストし、返されるものが「コントラクト」と一致するかどうかを確認するために、2つのアプリケーション間の統合を個別に検証する方法です。
コントラクトテストは、アジャイル設定で動作するマイクロサービスアーキテクチャにうまく適合します。したがって、例は、この環境での作業中に得た経験に基づいています。
学習内容：
この契約テストシリーズのチュートリアルのリスト
チュートリアル＃1： 例を使用した契約テストの概要 (このチュートリアル)
チュートリアル＃2： JavaScriptで消費者協定テストを書く方法
チュートリアル＃3： 協定ブローカーに協定契約を公開する方法
チュートリアル＃4： PactCLIを使用してPact契約と継続的デプロイを確認する
消費者主導の契約テスト
開始点は、テストの契約を形成するAPIドキュメントです。この時点で、通常、開発チームはAPIドキュメントを取得し、wikiドキュメント（またはWordドキュメントなどの組織内に存在する形式）に対して開発します。
例えば、 フロントエンドがTeamKryptonによって開発され、APIがTeamThoronによって開発されているWebアプリケーション。プロジェクトは、要件が提示され、チーム間で合意されるキックオフミーティングから始まります。
各チームは要件を満たし、ストーリーを洗練することでバックログの作成を開始します。開発はユーザーストーリーに従って両方のチームで開始され、統合テストは後のスプリントのために残されます。チームクリプトンが追加の要件を見つけると、エラーシナリオに関連して、APIドキュメントがそれに応じて更新されます。
テストケースは、ドキュメントに基づいて更新されたシナリオに関連するTeamThoronによって追加されます。
このプロセスにはすでにいくつかの欠陥がありますが、幸運を祈ってさらにいくつか追加しました。
- APIドキュメントの変更が効果的に伝達されない場合があります。
- フロントエンドチームはバックエンドサービスをスタブアウトし、その逆も同様です。
- バックエンドチームは、ドキュメントに基づいて統合テストケースを作成します。
- 統合環境は、完全統合がテストされるのは初めてです。
- 統合環境と本番環境で異なるAPIバージョン。
消費者主導の契約テストには、消費者とプロバイダーの2つの側面があります。これは、マイクロサービスでのテストに関する従来の考え方が逆転するところです。
ザ・ 消費者 は、リクエストと予想される応答を含むシナリオのキュレーターです。これにより、フォローすることができます ベッドの法則 これは、APIが受け入れることができるものには柔軟性があり、送信されるものには保守的である必要があることを示しています。欠陥番号に戻って参照します。 1、3、および4では、ドキュメントの変更は消費者によって推進されます。
例えば、 Team Thoronが文字列フィールドを変更してnull値を受け入れない状況では、コンシューマーテストは変更を反映しないため、失敗します。または、少なくともチームクリプトンに変更が加えられるまでは。
(画像 ソース )
ザ・ プロバイダー コンシューマーによって提供されたシナリオを「開発」環境に対して検証します。これにより、マイクロサービスが強制できるようになります 並列変更 これは、API機能を拡張してから、新しいバージョンに移行する必要があることを示しています。欠陥番号に戻って参照します。 2、通常、バックエンドチームが独自のテスト要件のために作成するスタブは、以下を使用するコンシューマーシナリオに基づくことができます。 協定スタブサーバー 。
双方の拘束力のある要素は、チーム間で共有する必要のある「契約」です。協定は、と呼ばれる契約の共有を可能にするためのプラットフォームを提供します 協定ブローカー （マネージドサービスとして利用可能 Pactflow.io ）。
ザ・ ブローカ 消費者シナリオの出力を格納します。コントラクトは、APIのバージョンと一緒にブローカー内に保存されます。これにより、APIの複数のバージョンに対するテストが可能になるため、欠陥番号5で強調されているように、リリース前に互換性を確認できます。
従来のプラットフォームでのPactBrokerの追加の利点は、消費者の可視性です。すべてのコンシューマーがAPIの作成者に知られているわけではありません。特に、どのように消費されているかはわかりません。
特に、2つのAPIバージョンがサポートされていた場合、バージョン1（V1）内でデータの問題が発生し、APIが原因でした。 ダーティデータ データベース内。
変更はAPIのV1で実装され、本番環境にプッシュされましたが、コンシューマーはデータの問題を引き起こしている形式に依存していたため、APIとの統合が壊れていました。
それはどのように機能しますか
上記の例は認証フローを示しています。Webサービスでは、機密データにアクセスするためにユーザーが認証する必要があります。 WebサービスはAPIにリクエストを送信し、ユーザー名とパスワードを使用してトークンを生成します。 APIは、認証ヘッダーとしてデータ要求に追加されるベアラートークンを返します。
コンシューマーテストは、ユーザー名とパスワードを使用して本文を渡すことにより、トークンのPOSTリクエストを作成します。
作成したリクエストを検証するテスト中に、この例ではトークンの値を含む予想される応答とともに、モックサーバーが起動します。
消費者テストの出力は、契約契約ファイルを生成します。これは、バージョン1として協定ブローカーに保存されます。
次に、プロバイダーは、pactブローカーからバージョン1をプルし、要求と応答がコンシューマーの要件と一致することを確認することにより、ローカル環境に対してこの要求を再生します。
役割と責任
品質保証（QA）/テスター： Pact.ioを使用して契約を作成し、BAと協力してテストシナリオを生成します。
開発者： テストの作成と継続的インテグレーション（CI）で実装するためのAPIのラップを支援するQAとのペアリング。
ビジネスアナリスト（BA）： シナリオを生成し、アーキテクトと協力して影響を受ける関係者を検証します。
ソリューションアーキテクト （組織に存在しない場合があります）：APIの変更に対応し、実装時にBAと調整し、変更をコンシューマーに伝達します（Pact Brokerを使用して関係者を理解します）。
リリース管理： （はい、それは昔ながらのことですが、私の世界にはまだ存在しています）：契約テストの対象範囲により、変更が正常にリリースされるという自信に満ちています。
チーム全員： 結果を確認して、PactCLIツールを使用してリリースを本番環境にプッシュできるかどうかを判断します。 デプロイできますか 。
契約テストと統合テスト
実稼働環境に昇格する前にシステムが機能しているかどうかを検証するには、統合テストが存在する必要がありますが、シナリオを大幅に減らすことができます。
これによる影響は次のとおりです。
- 統合環境にリリースする前のフィードバックの高速化。
- 統合環境の安定性への依存度が低くなります。
- 複数のAPIバージョンをサポートする環境が少なくなります。
- 統合の問題による不安定な環境インスタンスを削減しました。
| 統合 | 契約する | |
|---|---|---|
| 障害を明確に特定する | 多くの層 | 非常に簡単 |
| API構成 | はい | 番号 |
| 展開チェック | はい | 番号 |
| APIバージョン管理 | はい | はい |
| ローカルでデバッグする | 番号 | はい |
| 環境問題 | はい | 番号 |
| フィードバック時間 | スロー | 速い |
まず、契約テストは統合テストに取って代わるものではありません。ただし、既存の統合テストシナリオの一部を置き換え、左にシフトして、ソフトウェア開発ライフサイクルへのフィードバックを高速化できる可能性があります。
統合テストでは、環境アーキテクチャ、デプロイメントプロセスなど、APIが存在するコンテキストを検証します。
したがって、構成を確認するコアテストシナリオを実行する必要があります。 例えば、 APIバージョンのヘルスチェックエンドポイント。また、200応答を返すことにより、展開が成功したかどうかを証明します。
コントラクトテストでは、APIの詳細をテストします。これには、API構造、コンテンツ（フィールド値、キーが存在するなど）、エラー応答に関連するエッジケースが含まれます。 例えば、 APIはnull値を処理しますか、それともAPI応答から削除されますか（別の実際の例）。
いくつかのメリット（まだ販売されていない場合）
以下にリストされているのは、契約テストをより幅広いビジネスに販売する際に利用できるいくつかの利点です。
- ソフトウェアのより迅速な展開
- 信頼できる唯一の情報源
- すべての消費者の可視性
- さまざまなAPIバージョンに対するテストのしやすさ。
よくある質問
契約テストを採用するように人々を説得しようとする際のいくつかの一般的な質問は次のとおりです。
Q＃1）すでに100％のテストカバレッジがあるので、それは必要ありません。
回答： それは不可能ですが、契約テストには、テストカバレッジ以外にも多くの利点があります。
Q＃2）APIの変更を伝達するのはソリューションアーキテクトの責任です。
回答： 品質はチーム全体の責任です。
Q＃3）APIチームのテストシナリオを作成するのはなぜですか？
回答： APIチームは、Webサービスがどのように機能するかを知らないので、なぜそれが責任を負う必要があるのでしょうか。
Q＃4）エンドツーエンドのテストは、他の統合ポイントを含む、最初から最後までのフロー全体をカバーします。
回答： テストを分割して1つのことをテストする理由は正確であり、システムのエンドツーエンドのフローをテストする責任はありません。システムがどのように機能するかはわかりません。
Q＃5）テストはどのチームのリポジトリにありますか？
回答： 両方とも。リポジトリ内のコンシューマーとリポジトリ内のプロバイダー。次に、中心点では、契約はどちらの外部にも存在します。
引数
これらは、テストのための契約への移行に関して、私たちが反論するのが難しいと思う議論です。
- 統合テストの生成に使用できるSwaggerドキュメントがすでに用意されています。
- チームは、API変更のための効果的なメカニズムを備えたフロントエンドサービスとバックエンドサービスの両方を所有しています。
継続的インテグレーション
これは継続的インテグレーションテストスイートにどのように適合しますか？コントラクトテストが存在するための望ましい場所は、ユニットテストです。
コンシューマーテストは、テスト以外の外部依存関係を必要としないモックサーバーを起動します。
プロバイダーテストにはAPIインスタンスが必要であるため、ローカルAPIは インメモリテストサーバー 。ただし、APIをローカルでラップするのが簡単でない場合、以前に使用した回避策は、環境をスピンアップし、プルリクエストの自動チェックの一部としてこの環境にコードをデプロイすることです。
4年の経験のための手動テスト面接の質問
(画像 ソース )
結論
このチュートリアルでは、コントラクトテストの意味と、マイクロサービスインフラストラクチャでの外観を学び、実際の例でどのように見えるかを確認しました。
コントラクトテストが統合テストを左にシフトするのにどのように役立つかについての教訓が得られました。さらに、統合の問題に関連するフィードバック時間を短縮することで、組織のコストを削減する方法を確認しました。
コントラクトテストは、技術テストのツールであるだけでなく、変更を伝達し、テストを1つのユニットとして奨励することにより、開発チームのコラボレーションを強化します。全体として、これは継続的デプロイへの移行を検討しているすべての人にとっての前提条件です。
次のチュートリアル
推奨読書
- JavaScriptで消費者協定テストを書く方法
- PactCLIを使用してPact契約と継続的デプロイを確認する
- 協定ブローカーに協定契約を公開する方法
- 継続的インテグレーションプロセス：ソフトウェアの品質を向上させ、リスクを軽減する方法
- 単体テスト、統合テスト、機能テストの違い
- 統合テストとは（統合テストの例を含むチュートリアル）
- 統合テストを作成するための統合テストツールトップ10
- DevOpsでの継続的デプロイ