DEV Community

Cover image for APIテスト用無料オープンソースCLIツール
Akira
Akira

Posted on • Originally published at apidog.com

APIテスト用無料オープンソースCLIツール

ほとんどのAPIテストチュートリアルはGUIを前提にしています。しかし、ターミナルで実行し、CIに組み込み、設定やテスト定義をコードレビューしたいなら、CLIベースのAPIテストが適しています。オープンソースのCLIツールでは、監査可能なライセンス、セルフホスト可能なバイナリ、リポジトリにコミットできる設定ファイルを利用できます。

今すぐApidogを試す

重要なのは「最速のツール」や「最小のバイナリ」ではなく、ライセンスと制御です。アカウント登録なしで自社ネットワークやCIランナー上で動かせるか、ソースコードがOSI承認ライセンスで公開されているか、ベンダーの価格変更後もパイプラインを維持できるかを確認しましょう。

この記事では、REST、GraphQL、HTTP APIをテストするための無料かつソースコードが利用可能なCLIツールを8つ紹介します。各ツールについて、ライセンス、インストール方法、最初に実行するコマンド、向いている用途をまとめます。ホスト型ツールも含めて比較したい場合は、ベストフリーAPIテストツールまとめを参照してください。ターミナルからエンドポイントを直接操作する方法は、REST APIテストのcurl代替ガイドで解説しています。

APIテストCLIにおける「オープンソース」の条件

無料でダウンロードできることと、オープンソースであることは同じではありません。本記事で扱うツールは、次の条件を満たします。

  • 正式なライセンスがある

    ソースコードがMIT、Apache-2.0、MPL-2.0、AGPL-3.0、BSDなどのOSI承認ライセンスで公開されています。利用条件を確認し、必要に応じてソースを監査・フォークできます。

  • セルフホスト可能で、アカウントが不要

    登録なしでローカルマシンやCIランナーから実行できます。

  • 活動状況を検証できる

    GitHub上でコミット履歴やIssueを確認できます。運用中のパイプラインに組み込む前に、保守状況を確認してください。

ライセンスは実装上の要件です。たとえばAGPL-3.0のk6は、k6を利用してサービスを構築・提供するケースではコピーレフト義務を確認する必要があります。一方、MITやApache-2.0はより寛容です。製品へ組み込む前に、必ずライセンス原文を確認しましょう。

Hurl: プレーンテキストでHTTPテストを書く

Hurlは、HTTPリクエストとレスポンス検証をプレーンテキストで記述するツールです。Rustで開発され、内部でlibcurlを使用し、単一バイナリとして配布されます。テスト定義がそのままHTTP通信として読めるため、プルリクエストでレビューしやすい点が特徴です。

インストールと実行 

brew install hurl
# または:
cargo install --locked hurl
Enter fullscreen mode Exit fullscreen mode

まずはログインAPIのレスポンスにトークンがあることを検証します。

cat > login.hurl <<'EOF'
POST https://api.example.com/login
{ "user": "acme", "pass": "s3cret" }

HTTP 200
[Asserts]
jsonpath "$.token" exists
EOF

hurl --test login.hurl
Enter fullscreen mode Exit fullscreen mode

向いているケース

  • Gitで管理するスモークテスト
  • 読みやすいHTTP契約チェック
  • CIでの単発・複数リクエスト検証

注意点

HurlはHTTPに特化しています。gRPCテストや負荷生成には対応していません。複雑なフローでは、スクリプトを書く代わりに複数の.hurlファイルを管理する構成になります。

Step CI: YAMLで宣言するAPIワークフロー

Step CIは、CI実行を前提にしたYAMLベースのワークフローランナーです。REST、GraphQL、gRPC、tRPC、SOAPを単一のワークフローファイルで扱えます。OpenAPIスキーマの検証や負荷テストにも対応しています。

インストールと実行 

npm install -g stepci
Enter fullscreen mode Exit fullscreen mode

workflow.ymlにステップ、チェック、値のキャプチャを定義して実行します。

stepci run workflow.yml
Enter fullscreen mode Exit fullscreen mode

向いているケース

  • 複数APIをまたぐログイン・購入・登録フロー
  • ローカルとCIで同じ定義を使いたいチーム
  • YAMLでAPIテストを宣言的に管理したい場合

注意点

MPL-2.0は弱いコピーレフトライセンスです。Step CI自身のファイルを変更する場合、その変更の公開義務を確認してください。アプリケーションのテストとして利用するだけなら、その義務は発生しません。

Schemathesis: OpenAPI・GraphQLスキーマからテストを生成する

Schemathesisは、OpenAPIまたはGraphQLスキーマからプロパティベーステストを生成します。PythonのHypothesisを利用し、入力値をファジングして500エラー、スキーマ違反、ドキュメントと異なるレスポンスを検出します。

インストールと実行 

uv pip install schemathesis
# または:
pip install schemathesis
Enter fullscreen mode Exit fullscreen mode

公開済みのOpenAPI定義を指定して実行します。

schemathesis run https://api.example.com/openapi.json
Enter fullscreen mode Exit fullscreen mode

向いているケース

  • リリース前にエッジケースを探索したい場合
  • OpenAPIスキーマをテストの入力として活用したい場合
  • 手動で想定しにくい異常系を検出したい場合

注意点

実行には正確なスキーマが必要です。大規模APIでは大量のテストケースが生成されるため、フックやオプションで対象を絞り込む必要があります。

Dredd: API仕様と実装の契約テスト

Dreddは、稼働中のAPIがOpenAPIまたはAPI Blueprintの記述どおりに動作するかを確認します。仕様に書かれたリクエストを実際のバックエンドへ送信し、レスポンスを仕様と比較します。

インストールと実行 

npm install -g dredd
Enter fullscreen mode Exit fullscreen mode

API BlueprintファイルとローカルAPIサーバーを指定します。

dredd apiary.apib http://127.0.0.1:3000
Enter fullscreen mode Exit fullscreen mode

向いているケース

  • APIドキュメントと実装の乖離を検出したい場合
  • CIで仕様準拠を確認したい場合
  • セットアップ・ティアダウン用フックを利用したい場合

注意点

Dreddのリポジトリは2024年11月にアーカイブされ、読み取り専用です。現在も動作しますが、将来的な修正は期待できません。継続的に保守されるスキーマ駆動ツールが必要な場合は、Schemathesisを優先してください。

k6: JavaScriptで負荷テストを記述する

k6はGrafanaが提供する負荷・パフォーマンステストツールです。JavaScriptまたはTypeScriptでシナリオを書き、Goベースのエンジンで多数の仮想ユーザーを実行できます。

インストールと実行 

brew install k6
Enter fullscreen mode Exit fullscreen mode

スタータースクリプトを生成して実行します。

k6 new script.js
k6 run script.js
Enter fullscreen mode Exit fullscreen mode

向いているケース

  • APIの負荷テスト
  • パフォーマンステスト
  • ソークテスト
  • 機能テストと同じリポジトリで負荷シナリオを管理する場合

注意点

k6は負荷試験向けです。詳細な契約アサーションを主目的にする場合は、HurlやSchemathesisなどを併用してください。また、AGPL-3.0の条件は、k6のコードを利用してサービスを構築・提供する場合に特に確認が必要です。

Newman: PostmanコレクションをCIで実行する

Newmanは、Postman公式のコマンドラインコレクションランナーです。既存のPostmanコレクションをデスクトップアプリなしで実行できるため、PostmanベースのテストをCIへ移行する際に使えます。

インストールと実行 

npm install -g newman
Enter fullscreen mode Exit fullscreen mode

コレクションと環境変数ファイルを指定します。

newman run my-collection.json -e staging-environment.json
Enter fullscreen mode Exit fullscreen mode

向いているケース

  • すでにPostmanコレクションを利用しているチーム
  • PostmanのテストをCIで実行したい場合
  • 既存コレクションをそのままパイプラインに組み込みたい場合

注意点

NewmanはPostmanコレクション形式に依存します。API設計、モック、テスト定義のための新しいフォーマットを提供するものではなく、既存コレクションを実行するツールです。

Tavern: pytestに統合するYAML APIテスト

Tavernは、YAMLでAPIテストを記述できるPythonライブラリ・CLI・pytestプラグインです。pytestのフィクスチャ、レポート、並列実行、CI連携をそのまま利用できます。REST、MQTT、gRPCをサポートします。

インストールと実行 

pip install tavern
Enter fullscreen mode Exit fullscreen mode

テストファイルを既存のpytestテストと同じ場所に置いて実行します。

pytest test_login.tavern.yaml
Enter fullscreen mode Exit fullscreen mode

向いているケース

  • pytestをすでに使っているPythonチーム
  • APIテストとユニットテストを同じテストスイートで管理したい場合
  • pytestのフィクスチャやレポートを再利用したい場合

注意点

Pythonとpytestのテスト環境を前提とします。Python以外が中心の技術スタックでは、pytestへの依存が導入障壁になる可能性があります。

Venom: 複数エグゼキュータを組み合わせる統合テスト

OVHcloudのVenomは、HTTP、シェルスクリプト、IMAP、Web、データベースなど、複数のエグゼキュータを横断する統合テストツールです。YAMLテストスイートを実行し、CIで利用しやすいxUnit形式の結果ファイルを出力します。

インストールと実行

GitHubリリースからバイナリをダウンロード後、テストスイートを実行します。

venom run testsuite.yml
Enter fullscreen mode Exit fullscreen mode

向いているケース

  • API呼び出し後にデータベース状態も確認したい場合
  • HTTP、スクリプト、メール、DBチェックを単一フローに含める場合
  • エンドツーエンドテストの結果をxUnit形式で出力したい場合

注意点

対応エグゼキュータが多いため、YAML定義は冗長になりやすい傾向があります。リポジトリ内の例を参考に、必要なエグゼキュータから段階的に導入するとよいでしょう。

Apidogの立ち位置

Apidogはオープンソースではありません。無料プランを提供する商用製品であり、監査可能なライセンスを必須条件にする場合は、前述の8ツールから選ぶ必要があります。

一方で、複数ツールの組み合わせを管理する代わりに、設計、テスト、モック、ドキュメントを一つの環境で扱いたい場合は選択肢になります。Apidogは、apidog-cliを使ってターミナルやCIからテストを実行できます。

npm install -g apidog-cli

apidog login --with-token <YOUR_TOKEN>
apidog run --access-token <TOKEN>
# 全テスト成功: 終了コード 0
# テスト失敗: 非0
Enter fullscreen mode Exit fullscreen mode

出力にはagentHints.nextStepsを含む構造化JSONが含まれ、スクリプトやAIエージェントとの連携に利用できます。コマンド一覧と利用方法は、完全なapidog-cliガイドを参照してください。

選び方

ツール 最適な用途 インストール オープンソース？ ライセンス
Hurl Gitで管理するプレーンテキストHTTPアサーション brew install hurl はい Apache-2.0
Step CI 宣言型CIワークフロー npm i -g stepci はい MPL-2.0
Schemathesis スキーマからのプロパティベースファジング pip install schemathesis はい MIT
Dredd ドキュメントと実装の契約テスト npm i -g dredd はい（アーカイブ済み） MIT
k6 負荷・パフォーマンステスト brew install k6 はい AGPL-3.0
Newman CIでのPostmanコレクション実行 npm i -g newman はい Apache-2.0
Tavern pytest内のAPIテスト pip install tavern はい MIT
Venom マルチエグゼキュータ統合テスト GitHubリリース はい BSD
apidog-cli 設計からテストまでの統合ワークフロー npm i -g apidog-cli いいえ（無料プランあり） 商用

選定時は、まずテスト対象を分けると判断しやすくなります。

  • 単純なHTTPリクエスト検証: Hurl、Newman
  • OpenAPI・GraphQLスキーマからのバグ探索: Schemathesis
  • 仕様と実装の一致確認: Dredd
  • 負荷・性能検証: k6
  • pytestに統合したAPIテスト: Tavern
  • API以外も含む統合テスト: Venom
  • 設計・モック・テスト・ドキュメントをまとめたい場合: Apidog

テスト戦略全体の中で各手法を整理したい場合は、APIテスト戦略ガイドを参照してください。また、UIを使わずにAPIテストを実行する選択肢は、ヘッドレスAPIテストツールの記事で解説しています。

まとめ

オープンソースのCLIツールを使うと、APIテストの実行環境を自分で監査し、フォークし、自社の条件で運用できます。

  • HurlとNewmanは日常的なHTTPリクエスト検証
  • SchemathesisとDreddは仕様・契約の検証
  • k6は性能と負荷の確認
  • TavernとVenomはより大きなテストスイートへの統合

ライセンス、既存のテスト資産、CI環境、必要なテスト種類に基づいて選びましょう。単一ツールに統一する必要はありません。たとえば、Hurlでスモークテスト、Schemathesisでスキーマテスト、k6で負荷テストを実行する構成も実用的です。

設計、テスト、モック、ドキュメントを一か所で管理したい場合は、ApidogとCI向けのapidog-cliを検討できます。Apidogをダウンロードし、既存のCLIツールと比較しながら、自分のパイプラインに合う構成を確認してください。

Top comments (0)