Pactの最高の代替

Pactは、コンシューマー主導のコントラクトテストにおける標準的なツールです。コンシューマーはコントラクトを生成するユニットテストを作成し、プロバイダーはそのコントラクトを実際のコードに対してリプレイし、Pact Brokerが結果を保存し、can-i-deployはバージョンが出荷可能かどうかをパイプラインに伝えます。このループが実行されると、単独のユニットテストでは決して見つけられないような統合上の問題を検出します。しかし、問題はそのループ自体にあります。各コンシューマーチームでの言語ごとのテストDSL、スクリプト作成と維持が必要なプロバイダーの状態、ホストおよびバージョン管理が必要なブローカー、そしてローカルで再現できない理由で失敗するプロバイダー検証ビルドなどです。多くのチームが、たった一つの不安定な統合のためにPactを導入し、結果として小規模なコントラクトテストプラットフォームの運営に人員を割くことになります。

まず、その範囲を明確に述べた直接的な回答です。実際の課題がプロデューサーとコンシューマー間のスキーマのずれ（これはほとんどのチームに当てはまります）であるチームにとって、ApidogはPactの最良の代替ツールです。Apidogは、Pact生成の手間を、真の情報源となる単一のOpenAPI仕様に置き換え、すべてのテスト実行でそのスキーマに対してすべてのレスポンスを検証し、仕様からスマートモックを提供することで、プロバイダーが出荷する前にコンシューマーがコントラクトに基づいて開発できるようにし、Apidog CLIを通じてCIですべてを実行します。しかし、ApidogがPactのコンシューマー主導のブローカーワークフローを再現することはありません。つまり、pactファイルも、マトリックスも、can-i-deployもありません。多くの独立してデプロイするチーム間でその正確な仕組みが必要な場合、Pactはその本領を発揮します。この点については、以下で詳しく述べます。

Pactが実際にしていること、そして得意とすること

Pactのドキュメントでは、HTTPおよびメッセージ統合をテストするためのコードファーストなツールと説明されています。このモデルはコンシューマー主導型です。コンシューマーのテストはPactモックプロバイダーに対して実行され、具体的なリクエスト/レスポンスのペアをpactファイルに記録します。コンシューマーが使用するフィールドのみが記録されるため、プロバイダーは誰も依存しないものを自由にPactに変更できます。その後、プロバイダーは、各インタラクションが必要とするデータをプロバイダーの状態が設定した上で、実際のコードベースに対してこれらのリクエストをリプレイすることでpactを検証します。

Pact Brokerは、これらのアーティファクトをデプロイメントロジックに変換します。検証済みのすべてのコンシューマーとプロバイダーのバージョンペアはマトリックスに記録され、can-i-deployは、出荷しようとしているバージョンが、ターゲット環境で既に実行されているすべてのものに対して正常に検証されたかどうかをチェックします。終了コード0は出荷可能、1は出荷不可を意味します。

そのエコシステムは広範で、JVM、JavaScript、Go、.NET、Python、Ruby、Rust、PHP、Swiftなど10以上の言語で公式実装が存在し、そのほとんどがネイティブのRustコアを共有しています。また、ブローカーのセルフホスティングはかなりの作業であるため、SmartBearは、無料のStarterティア（2つの統合）、50の統合で月額127ドルのTeamティア、そしてSSOとオンプレミスオプションを備えたカスタム価格のEnterpriseティアを提供するマネージドブローカーであるPactFlowを販売しています。

儀式が積み重なるところ

問題は、「ループを実行する」ことが実際にどれだけのコストになるかという点です。

すべてのコンシューマーチームがDSLコードを作成する。 Pactはテストコードから生成されるため、各コンシューマーチームはその言語のPact DSLを学習する必要があり、多言語組織では複数のDSLを学習することになります。マッチングルールやモックの設定は、永久に書き、レビューし、リファクタリングするコードです。

プロバイダーの状態は隠れたテストスイートである。 各インタラクションには状態（「未払いの請求書を持つユーザー42が存在する」など）が必要となる場合があり、プロバイダーチームはそれを構築するハンドラーを実装しなければなりません。コンシューマーが増えるにつれて、プロバイダーは自身が制御できないデータ形状に対する状態ハンドラーのカタログを維持することになります。

ブローカーはインフラである。 セルフホストの場合、データベース、アップグレード、認証、すべてのCIシステムへのWebhookが必要です。マネージドサービスの場合、別のベンダーに依存することになります。いずれにせよ、バージョン管理の規律（ブランチ名、環境記録、保留中のpact）は、それに触れるすべてのチームに教える必要があります。

プロバイダー検証が不安定である。 検証は、コンシューマーが記録したリクエストをライブのプロバイダーインスタンスに対してリプレイします。これには、プロバイダー全体のランタイム（データベースシード、認証スタブ、バックグラウンドジョブ）が引きずり込まれます。ビルドが赤信号になると、失敗したテストは別のチームによって作成されたものであり、can-i-deployを通じてそのデプロイをブロックします。このようなチーム間のデバッグセッションが、チームがこっそりチェックをスキップし始めるきっかけとなります。

PactFlow自体もこの負担を認識しています。その双方向コントラクトテストは、リプレイステップを省略します。プロバイダーはOpenAPIドキュメントをコントラクトとして公開し、コンシューマーはモックから派生したコントラクトを公開し、PactFlowがこれら2つを静的に比較します。これは、多くの統合においてスキーマの比較で十分であるという、ベンダーが認めた事実です。そして、もし仕様がコントラクトであるならば、残りの仕組みは何の役立つのでしょうか？私たちは双方向コントラクトテストで同様の議論を行いました。

その答え：Apidog

Apidogは50万人以上の開発者に利用されているAPI開発プラットフォームです。Apidogは1つのOpenAPI仕様を中心として据え、そこからドキュメント、モックサーバー、リクエスト検証、自動テストなど、その他すべてのものを生成します。Pactの代替として、Apidogが提唱するのは、APIコントラクトテストで述べたコントラクトの異なる理論です。それは「仕様をコントラクトとし、それを機械的にあらゆる場所で強制する」というものです。

1. 1つのコントラクト、ゼロのDSL。 仕様はプロデューサーとコンシューマー間の合意です。誰も5つの言語でpact生成コードを書く必要はありません。チームは1つのドキュメントを視覚的に、またはコードとして読み書きします。
2. すべての実行におけるスキーマ検証。 Apidogで送信するすべてのリクエスト、およびCIでのすべてのテストシナリオは、仕様に対して自動的にレスポンスを検証します。フィールド名の変更、型変更、またはプロパティの削除は、誰もアサーションを書くことなく実行を失敗させます。これこそが、ほとんどのチームがPactを導入した目的である「ずれ検出」です。
3. コンシューマーは初日からコントラクトに基づいて開発する。 スマートモックサーバーは、エンドポイントが定義された瞬間に、現実的でスキーマに基づいたレスポンスを提供します。プロバイダーの状態をスクリプト化する必要はありません。モックは手作業ではなく生成されます。
4. ブローカーなしでのCI強制。 apidog runは、任意のパイプラインでテストシナリオを実行します。仕様を破るプロバイダービルドは、デプロイされる前に自身のCIで失敗します。これは「破壊的な変更を出荷しない」というPactと同じ結果ですが、マトリックスではなくソースで強制されます。

移行の様子を細かく見ていく

コントラクトそのもの

Pactでは、コントラクトは例示されたインタラクションの生成されたJSONファイルであり、あるコンシューマーが観察した内容を記述します。Apidogでは、コントラクトはOpenAPI仕様であり、すべてのエンドポイントの型、必須フィールド、列挙型、エラー形状が、ブランチベースのバージョン管理と共に一箇所で管理されます。トレードオフは明確です。Pactのコンシューマーごとのスライスは、プロバイダーにどのフィールドが変更しても安全かを正確に伝えますが、共有された仕様にはその利用シグナルはありません。その代わりに仕様がもたらすのは、ドキュメント、モック、テスト、クライアントのすべてが合意する単一の成果物です。この枠組みについては、APIコントラクトとはで詳しく説明しています。

プロバイダー側の検証

Pactは、ライブのプロバイダーに対してコンシューマーのインタラクションをリプレイします。Apidogの同等の機能は、CLIを介してCIで、スキーマ検証をオンにして実際のインプリメンテーションに対してテストシナリオを実行することです。プロバイダーは依然としてコントラクトに対して検証されますが、コンシューマーが作成した状態のカタログは必要ありません。

コンシューマー側の開発

Pactは、各コンシューマーのユニットテスト内でモックプロバイダーを提供します。Apidogは、すべてのコンシューマーに仕様から派生した動作するモックURLを提供し、チーム間で共有可能で、特定のデータが必要な場合にはカスタムの期待値も設定できます。フロントエンドチームやダウンストリームチームは、プロバイダーが一行も実装する前に開発を開始できます。仕様駆動型モックと手作りのモックの比較については、コントラクトテストとモックサーバーを参照してください。

デプロイメントゲーティング

これはPactの最も強力な機能であり、Apidogはこれをコピーしていません。サービス間のマトリックスもcan-i-deployもありません。代わりにApidogはコントラクトレベルでゲートを行います。仕様に違反するプロバイダーの変更は、プロバイダーのパイプラインを失敗させ、仕様の変更は、すべてのコンシューマーのためにモックとドキュメントを一度に再生成する明示的でレビュー済みのイベントです。いくつかの調整されたパイプラインを通じてサービスがデプロイされる場合、コントラクトレベルのゲーティングが80%のケースを占めます。何十ものチームが不定期に独立してデプロイする場合、マトリックスレベルのゲーティングは依然としてその価値があります。

PactとPactFlow vs Apidogの比較概要

コストとフィットの正直な計算

Pactのライブラリはオープンソースであり、永続的に無料です。支払うべきは調整費用です。ブローカーホスティングまたはPactFlow（チームプランは月額127ドル、年間請求で約1,385ドル）、さらにDSLテスト、状態ハンドラー、チーム間の検証デバッグが消費するエンジニアリング時間です。この時間が実際のコストであり、統合の数に比例して増加します。

Apidogの無料プランは、スペックエディター、無制限のモックサーバー利用、テストシナリオ、スキーマ検証、CLI実行を4ユーザーまでカバーし、有料プランは月額9ドル/ユーザーから始まります。したがって、比較対象はライセンス料ではありません。むしろ、コントラクトテストの仕組みを維持したいのか、それともいずれにせよ欲しくなるAPIクライアントと契約作業が一体となったプラットフォームを採用したいのか、ということです（ツールの統合？最高のPostman代替品から始めましょう）。ゼロからスペックファーストのスタックを選択するチームは、コントラクトファースト開発ツールスタックで各要素がどのように適合するかを確認できます。

Pactからの移行

pactファイルを変換するのではなく、仕様をコントラクトとして昇格させます。

1. 真のOpenAPI仕様を入手する。 既にある場合はApidogにインポートしてください。すぐにライブドキュメント、モック、検証ルールとして機能します。ない場合は、コードアノテーションから生成するか、pactファイルをコンシューマーが実際に利用するエンドポイントのチェックリストとして使用して作成します。
2. CIでスキーマ検証を有効にする。 プロバイダーのエンドポイントのテストシナリオを作成し、プロバイダーのすべてのビルドでCLIを使って実行します。これにより、プロバイダー検証が置き換えられます。
3. コンシューマーをスマートモックに向ける。 コンシューマーごとのPactモック設定を、ホストされたモックURLに置き換えます。各コンシューマーが切り替わるにつれて、DSLコードを削除します。
4. デプロイではなく仕様変更をゲートする。 仕様の編集をブランチでのレビュー済み変更とし、破壊的な編集がインシデントになる前に目に見える差分となるようにします。
5. ブローカーは最後に廃止する。 独立したデプロイタイミングが実際のリスクである統合ではcan-i-deployを維持し、儀式的なものであった場所ではそれを廃止します。

Pactが依然として有効な場合

もし多くのチームが独自のスケジュールでサービスを独立してデプロイし、「バージョンXは現在実行中の他のすべてを考慮して、今すぐ本番環境に投入できるか」という機械で確認可能な回答が必要な場合、Pactのブローカーマトリックスとcan-i-deployはそのために特別に作られており、Apidogはそれらを再現しません。メッセージキューのコントラクトテストもPactの領域です。PactFlowの双方向モードは、エコシステムを離れることなくリプレイの儀式をなくしたい場合の中間ステップです。これは、仕様がコントラクトを担うことができるというApidogの前提を共有しています。しかし、チーム間のデプロイ順序ではなく、ずれ、モック、CIチェックが課題であるならば、Pactの恩恵の一部に対してPactの全費用を支払っていることになります。

よくある質問

ApidogはPactのようなコントラクトテストツールですか？

コントラクトの強制方法が異なります。Pactはテストコードからコンシューマーごとのコントラクトを生成し、プロバイダーに対してそれらをリプレイします。ApidogはOpenAPI仕様をコントラクトとし、すべてのリクエストとCI実行をそれに対して検証します。これにより、ブローカーワークフローなしでスキーマのずれに対応します。この違いについては、APIコントラクトテストで詳しく説明しています。

Apidogはcan-i-deployやPact Brokerをサポートしていますか？

いいえ。Apidogには検証マトリックスやサービス間のデプロイゲートはありません。そのゲートはコントラクトです。仕様に違反するビルドは、自身のパイプラインで失敗します。マトリックスレベルのゲーティングが必要なチームは、それらの統合に対してPactを維持すべきです。中間的なオプションは、双方向コントラクトテストで説明されている静的比較アプローチです。

ApidogはPactのコンシューマーモックを置き換えられますか？

はい、ほとんどの用途で可能です。スマートモックサーバーは、セットアップなしで仕様からスキーマに正確なレスポンスを生成し、特定のケースのためのカスタム期待値も設定できます。これにより、コンシューマーチームはモックプロバイダーDSLを書く代わりに、ライブのコントラクトURLに対してコーディングできます。より広範なツール環境については、コントラクトテストとモックツールを参照してください。

仕様に対するプロバイダーのファジングについてはどうですか？

Apidogのシナリオテストを仕様ベースのプロパティテスターと組み合わせることで、例のリプレイよりも広範なネガティブカバレッジを提供できます。主要なオプションについては、Schemathesisとはで比較しており、同じ仕様が両方のツールを駆動します。

PactFlowの費用はApidogと比較してどれくらいですか？

PactFlowのStarterティアは2つの統合まで無料です。チームプランは50の統合で月額127ドル（年間請求で約1,385ドル）で、エンタープライズはカスタム価格です。Apidogは4ユーザーまで無料で、有料プランは月額9ドル/ユーザーからで、コントラクトツールは別個のブローカーとして請求されるのではなく含まれています。キャプチャ・リプレイツールも比較しますか？最高のKeploy代替品を参照してください。

儀式を廃止し、コントラクトを保持する

もしPactのセットアップがスキーマのずれを検出するために存在するのであれば、コンシューマーがすでに求めているモックと共に、すべての実行で検証される単一の仕様からその保証を得ることができます。OpenAPIファイルをインポートし、CIにapidog runを組み込み、モックURLを配布します。Apidogをダウンロードするか、ブラウザで開始してください。4人チームなら費用はかかりませんし、維持する必要がなくなったブローカーこそが肝要です。