Pact と Postman や Insomnia などの REST API テスト ツールは何が違うのでしょうか?
この記事では、アプローチの違いと、さまざまな API テスト シナリオで Pact と Postman を使用するメリットとデメリットを説明します。
Postman
Postman は API 開発向けのコラボレーション プラットフォームで、API の検索とナビゲーションを容易にする IDE のような GUI と、CI パイプラインで実行可能な API プロバイダー チェックを自動化する NodeJS スクリプト言語を備えています。
Postman (と Newman) はブラックボックス形式のテストで、内部構造を考慮せずにテストするため、テスト対象システム (System under Test、略称 SUT) のコードに直接アクセスする必要がありません。API の検索やコラボレーション、API 機能テストの実行に理想的です。
Postman はプロバイダー専用のテスト ツールであるため、コンシューマー (Web アプリケーションやほかの API など) とプロバイダーの相互作用をテストすることはできません。
Postman のスクリーンショット
(出典: https://www.postman.com/use-cases/exploratory-testing/)
Pact
Pact は分散システム テスト フレームワークであり、コントラクト テストと呼ばれるアプローチで HTTP とメッセージの統合をテストするコード ファーストのツールです、Pactflow (または Pact Broker) と組み合わせることで、強力な継続的配信ツールになります。
Pact の主な目的は、コンシューマー (Web アプリケーションやほかの API など) とプロバイダー API の互換性を確認することです。確認のため、E2E 統合テスト スイートで一緒にテストする必要はありません。
Pact テストは、ほかのユニット テストと同様に記述され、コンシューマーとプロバイダーの動作に基づいた期待値を確認して、実際の実装に基づいたテストを行うため、テスト対象システムのコードベースにアクセスする必要があります。
API の非互換性を示す Pact のスクリーンショット
(出典: https://pactflow.io/blog/verification-results/)
比較
以下は、それぞれのツールの相違点をまとめたものです。
| Postman | Pact | |
|---|---|---|
| 用途 | HTTP API | HTTP API、メッセージ API、Web アプリ |
| 使用方法 | GUI、CLI (Newman) | コード/IDE/CLI |
| 言語 | NodeJS (スクリプト) | すべての主要言語 (11 種類)、CLI ツール |
| テスト形式 | ブラック ボックス (内部構造を考慮しないテスト) |
ホワイト ボックス (内部構造を考慮したテストでコードへのアクセスが必要) |
| テスト作成者 | 誰でも作成可能 (たとえば、別のチームのメンバーでも作成可能) |
開発者 |
| テスト カバレッジ | API プロバイダー | API コンシューマーと API プロバイダー |
| 機能テスト | ○ | × |
| コントラクト テスト | × | ○ |
| 統合互換性チェック | × | ○ |
メリットとデメリット
Postman
メリット
- 簡単に始めることができ、コーディングの知識はほとんど必要ない
- スキーマ (OAS、JSONSchema、GrahpQL など) をインポートし、テストや API 検索のベースとして使用できる
- Postman コレクションにより共有やコラボレーションが簡単
デメリット
- プロバイダー中心で API コンシューマーを考慮していない
- テスト コード以外にも保守が必要な、独立したテスト スイートを推奨している
- API の問題に対するフィードバックの遅れ (個別のテスト スイートが原因)
- 複雑な CI/CD パイプラインを管理するためのツールを提供していない
Pact
メリット
- コンシューマーとプロバイダーが協調して動作することを保証し、開発者にすばやくフィードバックを提供
- テスト対象システムの言語でネイティブに統合されたコードからテストが生成されるため、常に有効なテストが維持される
- 継続的配信パイプライン向けに設計された CLI ツールにより、独立してリリース可能なソフトウェア コンポーネントを実現
デメリット
- 始めるのがやや難しい場合がある
- 専門的なコーディング スキルが必要
- 製品チームの一員でない、またはソースコードにアクセスできない外部のテスト チームには適さない
使用例
Postman は、次のような場合に最適です。
- API の検索と発見
- 機能/E2E API テスト
- ソースコードにアクセスできない外部のテスト チーム
Pact は、次のような場合に最適です。
- API コンシューマーとプロバイダー間の破壊的な変更を防止する (コントラクト テスト)
- マイクロサービスや Web アプリケーションの継続的配信パイプラインの管理
- ソースコードにアクセスできる開発者
Postman でコントラクト テストができるか?
Postman を使って擬似的なコントラクト テストを行うことは可能です。コンシューマーのコード ベースと API 呼び出し方法を仮定し、それらのリクエストを特定のコンシューマーの Postman コレクションとして保存し、プロバイダーに CI プロセスの一部としてそのコレクションに対するテストを行わせます。しかし、実際の実装 (コード) に基づいていないツールは、Pact が保証するような価値を提供できません。
コードにアクセスできないため、テスト作成者は期待値を手動で設定する必要があり、時間の経過とともに期待値が実装から乖離したり、プロバイダーに対する不確実性が大きくなる可能性があります。たとえば、特定の領域について確信を持ってテストすることができません。コンシューマー コードが API プロバイダーとの相互作用を変更した場合、Postman スイートは手動で更新する必要があります。さもなければ、実際のコンシューマーから乖離する危険性があります。
このようなテストではソースコードにアクセスできる可能性が低いため、データや依存関係を無効にして、分離したユニット テストとして実行することは難しいでしょう。恐らく、E2E テストで、実際にデプロイされているプロバイダーのバージョンに対してテストを行う必要があります。
Postman は E2E 機能テストに適していますが、Pact はコントラクト テスト ツールです。
Tom Hombergs 氏の記事では、これらのアプローチのメリットとデメリットを比較しています。同記事の内容は、以下のように要約できます。最終的には、状況に応じて最適なトレードオフを選択する必要があります。場合によっては、2 つを組み合わせることも検討すべきです。
E2E、モック、および CDC テストのメリットとデメリット
(出典: https://reflectoring.io/7-reasons-for-consumer-driven-contracts/)
まとめ
Pact と Postman はどちらも API テスト ツールですが、目的が異なるため、補完ツールとして使うこともできます。たとえば、ある同僚は現在、開発中のチームと権限の管理機能の API を手動でテストし、検索するために Postman を使用しています。
Postman は API 機能テスト ツールで、Pact はコントラクト テスト ツールです。Pact を使用することで、分離された信頼性の高いテストにより、迅速にシステム間の互換性を保証できます。また、Postman と組み合わせることで、API の検索を容易にし、プロバイダーの API 機能テスト スイートを手に入れることも可能です。
Pactflow 製品に関するお問い合わせは、こちら。
この資料は、Pactflow の Web サイトで公開されている「How is Pact different to Postman?」の日本語参考訳です。
