金融機関がAPI契約テストを導入する理由とは？
金融サービスでは、内部APIと外部APIの両方が広範に使用されています。たとえば、フィンテックスタートアップは、オープンバンキングAPIを使用して資金移動を開始したり、取引を監視したりする場合があります。あるいは、銀行には、APIを使用して通信する内部のマイクロサービス、Webアプリケーション、モバイルアプリケーションがあるかもしれません。どちらの場合でも、失敗は許されません。
なぜ統合テストではなく契約テストを使用すべきなのか、Pactflowの双方向サポートがどのように契約テストをスケーラブルにするのか、そして金融サービス業界での成功事例について詳しく見ていきましょう。
API契約テストは、統合テストやE2Eテストに伴う多くの問題を排除し、内部および外部のAPIコンシューマにとって堅牢なエクスペリエンスをより簡単に保証します。
API契約テストの理由
多くの金融機関は、マイクロサービス、Webアプリケーション、モバイルアプリケーションが通信できることを検証するために統合テストを使用しています。いくつかの統合テストがありますが、最も一般的なのはエンドツーエンドテスト（E2E）であり、本番に近い環境ですべてを展開し、一連のテストシナリオを実行します。
残念ながら、統合テストは非常に時間がかかり、保守が困難です。たとえば、テストエンジニアは、テストを実行する前にすべてのシステムが正しい状態にあることを確認する必要があります。さらに悪いことに、分散システムやリモートシステムで失敗したテストをデバッグすることはほとんど不可能です。そして最後に、これらの問題は大規模になるとさらに複雑になる傾向があります。
契約テストは、2つのサービス間の相互作用をキャプチャして契約に保存することでこれらの問題を解決します。スキーマテストやその他の方法論に似ていますが、契約テストでは両当事者が合意に達する必要はありません。代わりに、各システムを単独でテストすることができ、自動化によって契約が最新の状態に保たれます。
Pactがどのように役立つか
Pactは、統合ポイントの両側のコードにアクセスする必要があるコードファーストのコンシューマ駆動型契約テストツールです。コンシューマは、プロバイダのサーバーの状態を操作できる単体テストを作成します。これにより、コンシューマは、E2Eテストの最終段階に到達するずっと前に、自分のアプリがプロバイダのインフラストラクチャと連携することを確認できます。
- コンシューマはプロバイダのモックに対して自身の動作を単体テストします
- システム間の必要な相互作用を文書化した契約。
- 契約はチーム間で共有され、コラボレーションを可能にします。
- 契約内のリクエストはプロバイダAPIに対してリプレイされ、コンシューマの期待値に対して検証されます。
- プロバイダは他のシステムをモックアウトして、それらを分離してテストします。
プロバイダ駆動型契約テストツールとは異なり、Pact契約は自動化されたコンシューマテストの実行中に生成されます。その結果、テストはコンシューマが実際に使用するAPIの一部のみをカバーし、テストは時間の経過とともに自動的に進化します。効果を維持するために静的な契約テスト仕様を最新の状態に保つ必要はありません。
双方向サポートの追加
Pactの機能を拡張する契約テストツールであるPactflowは、さらに柔軟性を提供する双方向契約をサポートしています。このツールにより、コンシューマとプロバイダはそれぞれ独自の統合バージョンを公開できます。そして、相互の互換性を確保するためにクロス契約検証を使用できます。
Pactflowにおけるクロス契約検証ワークフロー。出典: Pactflow
プロバイダ契約とコンシューマ契約を分離することにより、双方向サポートはコンシューマが変更を行い、デプロイ可能かどうかを即座に判断することを可能にします。同時に、プロバイダはプロバイダの状態の管理や多くの例の維持について心配する必要はありません。分散チーム、複数のサービス、さまざまな統合ポイントも問題ありません！
Pactflowは、チームとロールベースのアクセス、セキュアな認証、監査ログなど、チームと企業が契約テストイニシアチブを開始し、スケールアップできるように設計された他のいくつかの機能も提供します。また、簡素化されたローカル開発のためのホスト型スタブ、プルリクエストのステータスチェック、Webhook、テストインサイト、暗号化されたシークレット、および構成ドリフトを回避し、CI/CDパイプラインがスムーズに実行されるようにするためのTerraformのサポートも提供します。
OpenAPI仕様との連携
Pactflowの双方向契約テストは、API仕様およびドキュメントツールであるOpenAPIとも連携します。実際、多くのAPIテストスイートは、OASなどのプロトコルを使用したスキーマベースのテストとして始まります。契約テストの必要性は、組織がより大規模なシステムとより高いレベルの複雑さに対処するにつれて、時間の経過とともに生じる傾向があります。
もちろん、SwaggerHub/OASにはテスト以外にも多くの利点があります。たとえば、APIモックツールは、コードなしで操作を簡単に仮想化できます。SDK生成ツールは、開発者向けの最新ライブラリの作成に役立ちます。スタイルバリデータは、開発者のIDEからAPI全体の一貫性を確保するのに役立ちます。
顧客成功事例
多くの大規模な金融サービス組織は、APIの安定性を確保するために契約テストを活用しています。
数万人のユーザーを抱えるシカゴを拠点とする個人金融アプリM1 Financeは、堅牢なバックエンドテストを実施していましたが、フロントエンドのAPIゲートウェイにはいくつかの統合テストとE2Eテストしかありませんでした。さらに、TypeScriptとGraphQLがある程度の安全性を提供していたものの、安定性を確保するための堅牢なテスト自動化ツールセットは持っていませんでした。
Pactflowによる契約テストを導入することで、同社はエンジニアリング部門と製品部門間のコミュニケーションとコラボレーションを改善し、時間のかかる手動テストプロセスを排除しました。OSS Pact Brokerとの概念実証から主要なステークホルダーを巻き込むまで、Pactflowの合理化された完全な契約テスト機能のおかげで、プロセスは6か月もかかりませんでした。
MastercardのLoyalty Rewardsアプリケーションも、Pactの契約テスト機能を extensively に使用しています。このアプリは、カード保有者がクレジットカードに応じて利用できるリベートプロモーションを設定するためにREST APIに依存しています。もちろん、REST APIの予期しない変更はアプリを破壊する可能性があり、大きなリスクを生み出します。
同社は、継続的インテグレーションおよびデプロイメント（CI/CD）プロセスにPact契約を実装し、契約を生成してブローカーに公開してプロバイダーが利用できるようにしました。プロバイダーはその後、独自のCI/CDパイプラインの一部として契約を取得し、それらに対して自動契約テストを実行しました。
結論
契約テストは、ソフトウェア開発ライフサイクルの早い段階で開発者にAPIエンドポイントに関する迅速かつ信頼性の高いフィードバックを提供することで、APIの統合テストとE2Eテストの最も問題の多い側面の多くを排除できます。コンシューマとプロバイダの間で契約を確立することにより、両当事者はAPI仕様の変更やその他の問題によって引き起こされるクラッシュや中断のリスクを最小限に抑えることができます。問題が発生した場合でも、開発プロセスの早い段階で、より迅速かつ簡単に解決できる場所で対処できます。
Pactflowを無料で試して、APIテストをレベルアップし、本番ユーザーに問題が到達するリスクを最小限に抑えるのがいかに簡単かを確認してください。