Keployを使い始めたチームなら、おそらくその一点を気に入っているでしょう。アプリを実行し、いくつかのエンドポイントを叩くと、テストが生成されます。アサーションを記述したり、依存関係を手動でスタブしたりする必要はありません。Keployはネットワーク層で実際のトラフィックをキャプチャし、それを再生します。
では、なぜKeployから移行したいと思う人がいるのでしょうか？通常、それは異なるニーズによるものです。キャプチャされたテストは、すでに発生したことの回帰を捕捉するのに優れていますが、チーム全体で読み、レビューし、所有するのは難しくなります。ある時点で、新しいエンジニアがプルリクエストで開いて一目で理解し、意図的に変更できるようなテストを求めるようになります。制御可能なテストデータ、フラグで切り替えられる環境、記録から派生するのではなく設計されたモックサーバーを求めているのです。
2つの異なるパラダイムを率直に比較
KeployとApidogは「APIテスト」という言葉で一部重複していますが、ツールのカテゴリは異なります。そうでないと偽ることは、あなたの不利益になります。
Keployは、分離されたテストサンドボックスを作成するためのオープンソースプラットフォームです。その特徴的な機能はレコード・アンド・リプレイです。ネットワーク層でeBPFを使用し、SDKやコードの変更なしに、実際のAPI呼び出しとその依存関係（データベースクエリ、ダウンストリームサービス、ストリーミングイベント）をキャプチャします。キャプチャされたトラフィックから、テストケースとそれらの依存関係のモックを自動生成します。また、OpenAPI仕様、Postmanコレクション、cURLコマンド、またはライブエンドポイントからテストスイートを構築するAIテスト生成パスも備えています。キャプチャはeBPF層で行われるため、言語に依存せず、Linuxと昇格された権限に依存します。ソースコードはGitHubで読むことができます。
ApidogはオールインワンのAPIプラットフォームです。設計、デバッグ、モック、ドキュメント作成、テストをすべて一か所で行えます。Apidog CLI（apidog run）は、ターミナルおよびCI/CDで、作成したテストシナリオとコレクションを実行します。データ駆動型テスト、環境切り替え、複数のレポート形式、クラウドレポートをサポートしています。ApidogにもAIテストケース生成機能がありますが、プロダクションのトラフィックを記録するのではなく、アプリ内のAPIスキーマとエンドポイントから動作します。
計画を立てる前に知っておくべき正直な点は次のとおりです。ApidogはeBPFを介してライブトラフィックをキャプチャせず、プロダクションの呼び出しと依存関係のモックを記録することでテストを自動生成しません。それがKeployの明確な強みです。もしランタイムキャプチャがワークフローの核であるなら、その仕事にはKeployを使い続けてください。Apidogに移行することで得られるのは、設計され、レビュー可能で、チーム横断的なテストと、APIライフサイクル全体をカバーするプラットフォームです。
| Keployのアプローチ | Apidogのアプローチ |
|---|---|
keploy recordがeBPFを介して実際のトラフィックをキャプチャ |
OpenAPI、Postman、またはcURLとしてAPIサーフェスをインポート |
| キャプチャされた呼び出しからテストが自動生成される | 仕様からのAIテストケース生成、および作成したシナリオ |
keploy test --delay 10が記録を再生 |
apidog runがCIで作成されたシナリオを実行 |
| 実際のDB/ネットワークトラフィックからキャプチャされた依存関係モック | 設計および制御するモックサーバー |
| 記録に組み込まれたテストデータ | 保守する-d (CSV/JSON) を介したデータ駆動型テスト |
| 記録された実行からの暗黙的な環境 | -eで切り替えられる明示的な環境 |
| Linux/eBPF、昇格された権限 | 標準のCIランナーを含む、CLIが実行される場所ならどこでも実行可能 |
この表は、機能のスコアカードではなく、翻訳ガイドとして読んでください。Keployの各機能は、Apidogにおける意図的なオーサリングステップに対応しています。「ツールがトラフィックから理解した」から「何が正しいかをあなたが記述した」へと変わります。
ステップ1：APIサーフェスを仕様としてキャプチャする
Keployは実行中のアプリから始まります。ApidogはAPIの記述から始まります。したがって、最初のタスクはその記述を取得することです。
すでにOpenAPIドキュメントを公開している場合は、それで完了です。それを指定して次に進んでください。そうでない場合は、いくつかのオプションがあり、そのすべてがインポート可能なものを生成します。
- フレームワークからOpenAPIを生成する（ほとんどのモダンなフレームワークには、OpenAPIを出力するエクスポーターまたはライブラリがあります）。
- チームがすでにPostmanコレクションを維持している場合は、それをエクスポートする。
- 各エンドポイントを叩くために使用するcURLコマンドを収集する。
良い副次効果として、Keployの記録がある場合、キャプチャされたリクエストは、実際にどのエンドポイントがどのようなペイロードで呼び出されるかの実際のインベントリになります。記録自体をインポートすることはありませんが、その記録をチェックリストとして使用し、仕様が同じサーフェスエリアをカバーするようにしてください。
ステップ2：Apidogにインポートする
Apidogをダウンロードし、プロジェクトを作成し、OpenAPIファイル、Postmanコレクション、またはcURLコマンドをインポートします。Apidogは仕様を読み込み、エンドポイント、リクエストスキーマ、パラメーター、およびレスポンスモデルを生成します。これで、Keployがヒットしていたのと同じサーフェスを持つ、すべてのエンドポイントの構造化された定義が得られますが、それは編集、バージョン管理、共有が可能な形式です。
ここでプラットフォームの違いが表れます。これらのインポートされたエンドポイントは単なるテストフィクスチャではありません。それらはライブドキュメントであり、デバッグ可能なリクエストであり、モックサーバーの基盤であり、すべて1回のインポートから得られます。ツールチェーンの詳細なウォークスルーについては、Apidog CLI完全ガイドで完全なセットアップをカバーしています。
ステップ3：初期テストスイートを生成し、実際のシナリオを作成する
ここでは、Keployで気に入っていたスピードの一部を取り戻します。ApidogのAIテストケース生成は、インポートしたスキーマとエンドポイントを読み込み、有効なリクエスト、境界値、および仕様に基づいた一般的な失敗レスポンスなど、テストケースをドラフトしてくれます。これは強力な出発点であり、白紙の状態から素早く始められます。この機能が他のツールと比較してどうであるかを知りたい場合は、最高のAIテストケースジェネレーターの概要でその文脈を理解できます。
正直な注意点が2つあります。第一に、AIによってドラフトされたケース（ApidogまたはKeployのいずれでも）には人間のチェックが必要です。出力をドラフトとして扱い、適用されないものを削除し、アサーションを厳密にしてください。第二に、これはランタイムの動作からではなく、仕様から生成されるため、実際のプロダクションデータの下でのみ現れる特異な動作については知りません。それはKeployのキャプチャが埋めていたまさにそのギャップであり、設計されたテストに移行する際に受け入れるギャップです。
そして、重要なシナリオを作成します。シナリオは、リクエストを実際のフローに連鎖させます。ユーザーを作成し、返されたトークンでログインし、プロフィールを取得し、更新し、削除します。ステータスコード、レスポンスフィールド、そしてデータが次のステップにどのように引き継がれるかについてアサーションを行います。これはKeployが記録内で暗黙的に行っていた作業です。明示的に行うことは、初期の労力は増えますが、後で誰かがテストを読み、レビューし、変更するたびに報われます。AIアシスタンスでテストケースを記述する方法に関するガイドは、生成と手動オーサリングのバランスを取るのに役立ちます。
ステップ4：環境とデータ駆動型入力を設定する
記録は1回の実行からの1組の値を伝えます。作成されたテストは、任意のデータセットを持つ任意の環境に対して実行されるべきです。
Apidogで（ローカル、ステージング、プロダクションなどの）環境を、それぞれ独自のベースURL、トークン、変数で定義します。実行時には、-eで1つを選択します。テストデータには、CSVまたはJSONファイルを添付し、Apidogは行ごとに各シナリオを1回実行するため、1つのログインシナリオで12種類の認証情報組み合わせをカバーできます。ファイルは-dで指定します。データ駆動型テストガイドでは、ファイル形式と変数バインディングについて詳しく説明しています。
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging" \
-d ./test-data/login-cases.csv
これは、固定された記録に対する具体的なアップグレードです。テストデータは、あなたが所有し、プルリクエストでレビューし、新しいエッジケースが現れるたびに拡張するファイルとなります。
ステップ5：apidog runでCIで実行する
パイプラインでkeploy testを置き換えるコマンドはapidog runです。これは、作成されたシナリオを実行し、選択された環境とデータファイルを適用し、レポートを出力します。CLI、HTML、JSON形式でレポートを生成でき、共有可能なリンクのために--upload-reportで結果をクラウドにプッシュできます。
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging" \
-r html,cli \
--upload-report
これをパイプラインに組み込む方法は、他のCIテストステップと同じ形式です。CLIをインストールし、トークンとシナリオIDを渡し、ゼロ以外の終了コードでビルドを失敗させます。CI/CDパイプラインガイドとGitHub Actionsウォークスルーでは、正確なYAMLについて説明し、テストレポートガイドでは、チームが実際に参照するであろう出力の読み方を説明しています。
ステップ6：制御するモックサーバーを構築する
Keployは、記録中に依存関係トラフィックをキャプチャすることで、モックを無料で提供します。Apidogは別のパスを取ります。つまり、あなたがモックを設計します。すでにスキーマをインポートしているので、Apidogはそれからモックサーバーを生成し、フィールドタイプと設定したルールに基づいて現実的な例のレスポンスを返します。レイテンシ、エラーケース、正確なペイロードを決定できます。
このトレードオフは、このガイドの他の箇所と同様です。キャプチャされたモックは依存関係が実際に行ったことを反映しますが、設計されたモックはあなたが彼らがすべきだと決めたことを反映します。契約テストと安定したCIの場合、設計されたモックは本番環境とは乖離しないため、優位に立つ傾向があります。より深い背景を知りたい場合は、契約テストとモックツール、およびOpenAPIスキーマからのモックデータ生成を参照してください。
得るものと諦めるもの
この移行の両面について、チームと正直に話し合いましょう。
自動キャプチャは諦めることになります。実際のトラフィックを監視するkeploy recordはなくなり、プロダクション実行から派生する依存関係モックもなくなり、ゼロコードを必要とするeBPFマジックもなくなります。もしその機能があなたにとって不可欠なものであれば、その仕事のためにKeployをツールボックスに残しておきましょう。これら2つのツールは共存できます。
あなたは、ドキュメントのように読めるテスト、フラグで切り替えられる環境、あなたが所有しレビューするテストデータ、あなたが設計するモックサーバー、そして設計、デバッグ、ドキュメント、テストのための単一プラットフォームを得ることができます。コストは現実的であり（記録よりも作成にはより多くの労力が必要）、その見返りはチーム全体が行動できる保守性です。APIテスト自動化ツールの広範な調査は、これらのトレードオフを文脈化し、ApidogでAPIをテストする方法は、次に読むのに良い実践的な内容です。
2つのツールを並べて検討している場合、Apidog vs Keployの比較は機能ごとに詳細を説明し、もしKeployが特にあなたのチームに合わない場合は、最高のKeploy代替案のまとめを見る価値があります。
よくある質問
Apidogは既存のKeployレコーディングをインポートできますか？ 直接はできません。Keployのレコーディングはランタイムキャプチャであり、ApidogはAPI仕様から動作します。現実的な方法は、APIサーフェスをOpenAPI（またはPostman/cURL）としてキャプチャし、それをインポートすることです。Keployのレコーディングは、どのエンドポイントをカバーすべきかのチェックリストとして使用してください。
ApidogはKeployのようにライブトラフィックを記録し、データベースを自動でモックしますか？ いいえ。ApidogはeBPFを介してトラフィックをキャプチャせず、実際の実行から依存関係モックを自動生成しません。それがKeployの明確な強みです。Apidogはスキーマからテストとモックを生成し、その上にシナリオを作成します。
keploy recordとkeploy testの代わりになるものは何ですか？ recordに相当するものはありません。代わりに、仕様をインポートし、AIで初期スイートを生成し、シナリオを作成し、keploy testの代わりにapidog runでそれらを実行します。
Keployから移行するために追加のオーサリング作業をする価値はありますか？ プルリクエストで読みやすく、レビュー可能で、チーム全体で所有されるテストが必要な場合は、はい。もし、依存関係モックを含む実際のランタイム動作をゼロの労力でキャプチャすることが主なニーズであれば、Keployは依然としてそれをより良く行えるため、その仕事にはKeployを使い続けてください。
両方のツールを同時に実行できますか？ はい。多くのチームは、キャプチャベースの回帰チェックにはKeployを、設計されたエンドツーエンドのスイート、ドキュメント、モックにはApidogを使用しています。それらは異なる問題を解決します。
どこから始めるか
一つのサービスを選んでください。そのOpenAPI仕様をエクスポートし、Apidogにインポートし、AIにいくつかのテストケースをドラフトさせ、その後、環境と小さなデータファイルで一つの実際のシナリオを作成してください。apidog runで実行し、CIに組み込んでください。このサイクルがうまくいけば、徐々に広げていきましょう。記録の利便性を犠牲にして、チーム全体が読み、変更し、信頼できるテストを手に入れることになります。CLI自体について深く知るには、インストールガイドとコマンドラインREST APIテストのウォークスルーから始めてください。