APIテストを手作業で書かずに作成する方法を探したことがあるなら、Keployに出会ったことがあるかもしれません。Keployは、実行中のアプリケーションを指し示し、実際のトラフィックを監視させれば、テストスイートを手に入れられるという、あまりにも便利に聞こえることを約束します。では、Keployは実際には内部で何をしているのでしょうか？そして、あなたのテストスタックにどのように適合するのでしょうか？
このガイドでは、Keployとは何か、その記録・再生エンジンがeBPFネットワーク層でどのように機能するか、提供される2つのワークフロー、インストールと実行方法、そして導入前に知っておくべき正直な限界について説明します。
Keployとは
Keployは、API、統合、およびエンドツーエンドテストのために安全で隔離された本番サンドボックスを作成するためのオープンソースプラットフォーム（Apache-2.0ライセンス）です。その核となる考え方は、実際のアプリケーションが既にテストしたい動作を実行しているということです。テストコードでその動作を記述するように求める代わりに、Keployはそれを観察し、再現可能なテストに変換します。
それを行うには2つの方法があります。
- 記録と再生（Record and replay）：実際のAPIインタラクションとその依存関係をキャプチャし、決定論的に再生します。
- AIテスト生成（AI test generation）：仕様、コレクション、cURLコマンド、またはライブエンドポイントから検証済みのAPIテストスイートを構築します。
どちらの方法も、ライブの依存関係にアクセスすることなくテストを実行するために必要なモックと、実行可能なテストを生成します。このプロジェクトはオープンソースであるため、コードを読んで自分でホストできます。リポジトリはgithub.com/keploy/keployにあり、公式ドキュメントはkeploy.io/docsにあります。
eBPF層でのKeployの記録の仕組み
これがKeployを特徴づける部分です。keploy recordを実行しても、SDKを追加したり、アプリケーションコードを1行も変更したりする必要はありません。eBPF（プログラムがシステムイベントを安全に監視し、作用できるようにするLinuxカーネル技術）を使用して、ネットワーク層でトラフィックをキャプチャします。
実際に得られるメリットは次のとおりです。
- コード不要のキャプチャ。 計測器もテストハーネスも、ハンドラーにデコレーターも不要です。Keployはアプリケーションの下に位置し、出入りするバイトを監視します。
- 言語に依存しないキャプチャ。 キャプチャがランタイム内ではなくカーネルネットワーク層で行われるため、サービスがGo、Python、Rustのいずれで書かれていても同じように機能します。
- 依存関係のキャプチャ。 KeployはインバウンドAPI呼び出しとその応答を記録するだけでなく、データベースクエリやネットワークまたはストリーミングイベントなど、サービスがその依存関係に対して行うアウトバウンド呼び出しも記録します。
最後の点が重要です。Keployがリクエストを記録するとき、APIリクエスト、API応答、そしてその間に発生したすべての依存関係呼び出しという、全体像をキャプチャします。そして、その単一の観察されたインタラクションから2つの成果物を生成します。
- 期待されるリクエストとレスポンスを記述するテストケース。
- 各依存関係呼び出しに対するモックとスタブ。これにより、ライブデータベースやダウンストリームサービスなしでテストを再生できます。
再生がこのループを閉じます。keploy testを実行すると、記録されたリクエストをアプリケーションに送り返し、生成されたモックからキャプチャされた依存関係の応答を提供し、新しい応答を記録された応答と比較します。不一致は、何かが変更されたことを意味します。これが、このアプローチが記録と再生（record and replay）と呼ばれる理由です。つまり、実際のランタイム動作を一度記録し、その後、変更があるたびにそれを回帰テストとして決定論的に再生するのです。
Keployの2つのワークフロー
記録と再生（Record and replay）
既に動作中のアプリケーションがあり、迅速に回帰テストカバレッジを確保したい場合にこれを使用します。Keployの下でアプリを実行し、実際のユーザーやクライアントが行うように（手動呼び出し、既存の統合テスト、またはライブトラフィックによって）操作すると、Keployは各インタラクションをテストとそのモックとして保存します。その後の実行では、これらのインタラクションを再生し、動作のずれがあればそれを通知します。
AIテスト生成（AI test generation）
手動操作で得られた以上の幅広いカバレッジが必要な場合、あるいは実行中のフローではなく契約から始める場合にこれを使用します。Keployは、OpenAPI仕様、Postmanコレクション、cURLコマンド、またはライブエンドポイントから検証済みのAPIテストスイートを生成できます。依存関係を自動的にモックし、自動クリーンアップパスを実行するため、冗長なケースが残ることはありません。
2つのワークフローは相補的です。記録と再生は実際の観察された動作に基づいてテストを確立し、AIテスト生成は仕様からのギャップを埋めます。スキーマからテストを生成するツールを評価している場合は、AIテストケースジェネレーターのまとめとOpenAPIからテストスクリプトを生成するガイドが役立つでしょう。
Keployのインストール
Keployはインストールスクリプトを提供しています。サポートされているシステムでは、以下を実行します。
curl --silent -O -L https://keploy.io/install.sh && source install.sh
これにより、バイナリがフェッチされ、keployコマンドが設定されます。そこから、2つのコマンドですべてを操作します。
Keployの主要コマンド
最もよく使うコマンドは2つあります。最初のコマンドは記録用です。
keploy record -c "CMD_TO_RUN_APP"
-cオプションを通じて、アプリケーションを起動する正確なコマンドを渡します。Keployはアプリを起動し、あなたが操作する間のトラフィックを監視し、キャプチャされたテストケースとモックを保存します。
2番目のコマンドは再生用です。
keploy test -c "CMD_TO_RUN_APP" --delay 10
--delay 10フラグは、Keployが記録されたリクエストの送信を開始する前に10秒待つように指示します。これにより、処理の遅いサービスが再生が始まる前に起動を完了する十分な時間が与えられます。アプリの起動にさらに時間がかかる場合はこの値を増やし、高速に起動する場合は減らすことができます。
典型的な初回セッションは次のようになります。
# 1. APIにアクセスしながら記録
keploy record -c "node server.js"
# 2. キャプチャされたケースを再生し、ドリフトがないかチェック
keploy test -c "node server.js" --delay 10
これが全体のループです。既知の良好なビルドに対して一度記録し、その後、変更があるたびにCIでkeploy testを実行します。
サポートされている言語、プロトコル、データストア
キャプチャはネットワーク層で行われるため、Keployは幅広い領域をカバーします。
| カテゴリ | サポート対象 |
|---|---|
| 言語 | Go, Java, Node.js, Python, Rust, C#, C/C++, TypeScript など |
| プロトコル | HTTP/REST, gRPC, GraphQL, Kafka, RabbitMQ |
| データストア | PostgreSQL, MySQL, MongoDB, Redis |
この広範なサポートは、eBPF設計の直接的な結果です。Keployはネットワーク通信を読み取るため、新しい言語やフレームワークがこれらのプロトコルのいずれかを話す限り、新しいプラグインは必要ありません。
CIでのKeployの実行
どちらのコマンドも自動化のために設計されています。パイプラインでは、記録されたテストケースとモックをコードと共にコミットし、その後、ステップとしてkeploy test -c "..."を実行します。モックが実際の依存関係の代わりを務めるため、CIランナーにライブデータベースやダウンストリームサービスは不要であり、ジョブを高速かつ決定論的に保ちます。再生が失敗すると、単体テストが失敗するのと同じようにビルドが失敗します。
考慮すべき正直な制限
Keployはその機能において強力ですが、あらゆる状況に適しているわけではありません。公平な評価にはトレードオフが含まれます。
- Linuxおよび管理者権限に偏重している。 eBPFはLinuxカーネルの機能であり、その層でのキャプチャには通常、管理者権限が必要です。これは、どこでどのように実行できるかを規定します。
- 生成されたテストはキュレーションが必要。 実際のトラフィックまたはAI生成から構築されたテストは出発点であり、完成したスイートではありません。ノイズをレビューして削減し、どのキャプチャされた動作が実際に強制する価値のある契約であるかを決定する必要があります。
- テストおよびテスト生成ツールであり、完全なAPIライフサイクルプラットフォームではない。 Keployはテストのキャプチャ、生成、再生に焦点を当てています。API設計、ドキュメント作成、コンシューマー向けのモックサーバー公開、API仕様に関するチームコラボレーションを処理するようには設計されていません。
これらはいずれもKeployに対する批判ではありません。これらはそのカテゴリの自然な境界線です。これらを知ることで、それが問題を解決するのか、それともその一部だけを解決するのかを判断するのに役立ちます。
デザインテストの代替としてのApidogの位置づけ
ニーズが「観測されたトラフィックを回帰テストに変換する」よりも幅広い場合、フルライフサイクルプラットフォームを検討する価値があります。Apidogは、APIの設計、デバッグ、モック、ドキュメント作成、テストをすべて一箇所でカバーするオールインワンAPIプラットフォームです。ApidogとKeployは異なるカテゴリに属するため、哲学の違いを理解することが重要です。
Keployは、コードなしで依存関係モックを含む実際のランタイム動作をキャプチャして再生します。Apidogはその逆のアプローチを取ります。保守可能なテストシナリオを設計および作成し、その後、Apidog CLIを使用してターミナルやCIから実行します。CLIは、CSVまたはJSONを介したデータ駆動型テスト、環境切り替え、およびCLI、HTML、JSONレポートで、作成したコレクションを実行します。Apidogはまた、アプリ内で作成されたAPIスキーマとエンドポイントからAIテストケース生成も提供しており、これが両ツールの重複する部分です。
その境界線を明確にするために言えば、ApidogはeBPFを介してライブトラフィックをキャプチャせず、本番呼び出しと依存関係モックを記録することによってテストを自動生成することもありません。実際のトラフィックからの記録機能は、純粋にKeployのものです。正直なところ、タスクに基づいて選択することになります。コードなしでランタイムのキャプチャと再生が必要な場合はKeployを選択してください。APIライフサイクルの残りの部分も処理するプラットフォーム内で、設計された保守可能なテストスイートが必要な場合はApidogを選択してください。より詳細な比較については、Apidog vs Keployを参照してください。もし切り替えを決定した場合は、移行ウォークスルーでテストの移行について説明しています。
保守可能で、自分で作成したAPIテストが必要な場合は、Apidogをダウンロードし、ApidogでAPIをテストする方法のガイドから始めることができます。
よくある質問
Keployは無料のオープンソースですか？ はい。KeployはApache-2.0ライセンスの下でオープンソースであり、コードはGitHubで公開されています。セルフホストも可能です。
Keployはアプリケーションコードの変更を必要としますか？ いいえ。記録・再生ワークフローはeBPFネットワーク層でトラフィックをキャプチャするため、SDKの追加やコード変更は不要です。これが多くの言語で機能する理由でもあります。
keploy testコマンドの--delayフラグは何をしますか？ このフラグは、Keployが記録されたリクエストを送信するまでに待機する秒数を設定し、アプリが起動する時間を与えます。--delay 10は10秒待ちます。起動の遅いサービスの場合はこの値を増やしてください。
Keployはテスト中にデータベースをモックできますか？ はい。インタラクションを記録する際、依存関係の呼び出し（データベースクエリなど）もキャプチャし、それらのモックを作成するため、再生はライブデータベースなしで実行されます。
KeployはAPI設計およびドキュメント作成ツールの代替となりますか？ いいえ。Keployはテストおよびテスト生成ツールです。API設計、ドキュメント作成、コンシューマー向けのモック、テストと並行したコラボレーションには、Apidogのようなフルライフサイクルプラットフォームの方が適しています。
要約
Keployは、実際のAPIの動作をテストに変換するオープンソースツールです。その記録・再生エンジンはeBPFを使用して、コード変更なしでネットワーク層でのリクエスト、レスポンス、依存関係呼び出しをキャプチャし、それらを決定論的な回帰テストとして再生します。AIテスト生成機能は、仕様やエンドポイントからスイートを構築します。迅速に導入可能で言語に依存しませんが、Linux寄りのキャプチャモデル、レビューが必要なテスト、テストに限定されたスコープというトレードオフがあります。完全なAPIプラットフォーム内で、作成され保守可能なテストスイートが必要な場合は、比較対象としてApidogが挙げられます。