Apidog CLI vs Postman CLI: より優れたCIテストランナーはどちらか

お使いのラップトップで「実行」をクリックすると、APIテストは合格するかもしれません。しかし、それは何も証明しません。重要なテストとは、人間が何もクリックすることなく、すべてのプルリクエスト、すべてのマージ、すべてのナイトリービルドで実行されるテストです。テストをそのループに組み込むのは、コマンドラインランナーの役割です。それは、あなたが既に作成したテストを受け取り、パイプライン内でGUIなしで実行し、CIが読み取れるステータスコードで終了し、ビルドダッシュボードに表示されるレポートを生成します。

チームがこれを設定する際、何度も話題に上がる2つのランナーがあります。Postman CLIとApidog CLIです。これらは異なる出発点から同じ目標を目指しています。Postman CLIは、Postmanで構築したコレクションを実行します。Apidog CLIは、Apidogで視覚的に構築したテストシナリオを実行します。どちらも1ステップでインストールでき、GitHub Actions、GitLab CI、Jenkinsに連携でき、テストが失敗するとビルドを赤くします。本当の違いは、実行コマンドのさらに前の段階にあります。つまり、テストの作成方法、CIでの認証方法、そしてテスト定義が実際にどこに存在するかに違いがあります。

💡

これは両者のコマンドレベルでの比較です。偽りの議論はありません。Postman CLIには多くの優れた点があり、パイプラインにどちらかを導入する前に、それぞれのランナーがどこに適合するかを正確に理解できるでしょう。Apidogを初めて使用する場合、これはデザイン、デバッグ、テスト、モック、ドキュメント作成を1つのワークスペースでカバーするオールインワンのAPIプラットフォームであり、CLIはテストを自動化に組み込むための要となります。

ボタン

TL;DR（要約）

Postman CLI（バイナリはpostman）は、Postmanワークスペースに保存されているコレクションを実行します。これはNewmanをベースにしており、Postman社によって署名されサポートされています。Postman APIキーで認証します。サインインしている場合、実行結果は自動的にPostmanクラウドに送られます。
Apidog CLI（apidog-cli、バイナリはapidog）は、Apidogで視覚的に設計したテストシナリオを実行します。アクセストークンとIDでシナリオを指定すると、GUIなしでそのシナリオをヘッドレスで実行します。
どちらもJUnit、JSON、HTML、ターミナルレポートを出力します。どちらもテストが失敗するとビルドを失敗させます。どちらの場合も、CIダッシュボードに接続するのはJUnit XMLです。
テストがすでにPostmanコレクションに存在し、チームがレポートと履歴のためにPostmanクラウドの使用を義務付けている場合は、Postman CLIを選択してください。
視覚的なシナリオ作成、リクエストの連結、環境管理、データ駆動型実行を単一の信頼できる情報源から行い、レポートをローカルに保持するかクラウドに送信するかを完全に制御したい場合は、Apidog CLIを選択してください。

本当の問題：存在するが一度も実行されないテスト

手動で実行するテストは、形骸化するテストです。誰かが作成し、一度は合格しましたが、その後はAPIが変更されても放置されていました。3か月後にはテストが間違っていても誰も気づきません。なぜなら、誰も実行しなかったからです。解決策はテストを増やすことではありません。既存のテストをすべての変更に対して自動的に実行させ、パイプラインが対処できる合否のシグナルを出すことです。

CLIランナーは、そのギャップを埋めるツールです。CIに組み込まれるためには、3つのことを行う必要があります。GUIなしで実行できること（CIランナーには画面がないため）。何かが失敗した場合にゼロ以外の終了コードを返すこと（ビルドが赤くなり、不完全なマージがブロックされるため）。そして、機械が読み取れるレポートを書き出すこと（レビュー担当者がローカルで再実行することなく、何が壊れたかを確認できるため）。Postman CLIとApidog CLIはどちらもこの基準をきれいにクリアしています。両者が分かれるのは、runコマンドより前に起こることすべてです。つまり、テストがどのように作成され、CIがそれを探すときにどこに存在するかに違いがあります。

自動テストをゼロから設定する場合、この情報と並行して、CI/CDでのAPIテスト自動化の広範なパターンを読む価値があります。ここでは、2つのランナーに焦点を当てます。

Postman CLIの得意な点

まず、多くの人が戸惑う明確な点として、Postman CLIはNewmanではありません。Newmanは、コミュニティが長年使用してきた、より古いオープンソースのnpmベースのランナーです。Postman CLIは、Newmanの基盤に基づいて構築された新しいツールですが、Postman社によって署名され、公式にサポートされています。Newmanを実行してきた場合、両者は互換性がなく、CIではその違いが重要になります。Postman側の2つの選択肢で迷っている場合は、Postman CLI vs Newmanでその正確な区別を詳しく説明しています。

Postman CLIの最大の強みは、チームがすでに慣れ親しんだ世界にとどまることです。コレクション、環境、共有変数が既にPostmanワークスペースに存在する場合、CLIはほとんど変換なしでそれらを実行します。何も再構築する必要はありません。認証し、コレクション名を指定すれば、アプリケーションが実行するのとまったく同じようにリクエストとテストが実行されます。

インストールは単一のコマンドです。macOSおよびLinuxでは、公式のインストールスクリプトを実行します。

curl -o- "https://dl-cli.pstmn.io/install/unix.sh" | sh

Windowsでは、署名付きのPowerShellインストーラーを使用します。開発依存関係として固定したい場合は、npmパッケージもあります。

npm install -g postman-cli

バイナリはpostmanです。CIでは、Postman APIキーで認証します。これはPostmanがパイプライン向けに推奨している方法です。

postman login --with-api-key $POSTMAN_API_KEY

その後、コレクションをIDで実行するか、エクスポートしている場合はローカルファイルパスで実行します。

postman collection run $POSTMAN_COLLECTION_ID -e $POSTMAN_ENV_ID

Postman CLIが多くの支持を得ているのは、実行後に起こることです。サインインしている場合、実行結果は直接Postmanクラウドに送信され、コレクションと共にワークスペースに表示されます。テスト履歴、実行比較、チームで共有できるダッシュボードがすべて、余分な設定なしで利用できます。Postmanをすでに利用しているチームにとって、このクラウドへの往復は非常に便利であり、使い続ける十分な理由となります。

Apidog CLIの得意な点

Apidogは、同じパイプラインに対し異なるアプローチを取ります。Apidogアプリ内でテストを視覚的に構築します。複数のリクエストを1つのテストシナリオに連結し、各レスポンスにアサーションを追加し、あるレスポンスから値を取り出して次のリクエストに渡し、データファイルを使ってシナリオ全体をループ実行します。CLIは、これらのシナリオのヘッドレス実行エンジンです。独自のテスト形式を持たず、Apidogプロジェクトにアクセスし、IDで指定されたシナリオを見つけ、アプリケーションが実行するのとまったく同じように実行し、結果を報告します。

その利点は、誰も同じテストを2つのコピーで管理する必要がないことです。ビジュアルエディタで構築したシナリオが、CIで実行されるテストとなります。動作するテストをスクリプトとして再表現し、その後スクリプトをデバッグするような手順は不要です。迅速なテスト作成と自動化のループが、単一の信頼できる情報源を共有します。ログイン、作成、読み込み、削除といった多段階のフローでは、ビジュアルなチェーンによって、手書きするであろう多くのグルーコードを省くことができます。これらのフローを構築する仕組みについては、APIテスト自動化のためのテストシナリオに関するガイドで説明されています。

インストールはnpmコマンド1つです。

npm install -g apidog-cli

バイナリはapidogです。一般的な実行では、シナリオをIDで指定し、環境を選択し、イテレーション数を設定し、アクセストークンで認証します。

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r html,junit

これらのIDを手動で入力する必要はありません。Apidogでテストシナリオを開き、そのCI/CDタブに切り替え、アクセストークンを生成すると、ApidogがシナリオIDと環境IDが事前に入力された完全なコマンドを生成します。それをコピーし、トークンをCIシークレットに移動させ、ワークフロー内で$APIDOG_ACCESS_TOKENとして参照するだけです。

トークンとIDのモデルは、Postman CLIとの最も明確な違いです。Apidogは、CLIがネットワーク経由でフェッチするプロジェクトに保存されているテストを、トークンで認証して実行します。レポートのために別途クラウドへのオプトインも不要です。ローカル成果物には--out-dirを選択し、概要をApidogクラウドにプッシュしたい場合にのみ--upload-reportを追加します。レポートは指定した場所に保持されます。

比較

項目	Postman CLI (`postman`)	Apidog CLI (`apidog`)
パッケージ / インストール	インストールスクリプト、署名付きインストーラー、または `npm i -g postman-cli`	`npm i -g apidog-cli`
実行コマンド	`postman collection run <id\|file>`	`apidog run -t <scenarioId>`
テストソース	Postmanワークスペース内のコレクション (またはエクスポートされたファイル)	Apidogプロジェクト内のテストシナリオ (IDでフェッチ)
作成方法	Postmanアプリのコレクションエディタ	Apidogアプリのビジュアルシナリオビルダー
CIでの認証	Postman APIキー (`postman login --with-api-key`)	アクセストークン (`--access-token`)
実行対象の選択	コレクションIDまたはファイルパス	`-t` シナリオ、`-f` フォルダ、`--test-suite`
環境	`-e, --environment`	`-e, --environment <environmentId>`
データ駆動	`-d, --iteration-data` (JSONまたはCSV)	`-d, --iteration-data` (JSONまたはCSV)
イテレーション	`-n, --iteration-count`	`-n, --iteration-count`
レポーター	`cli`, `json`, `junit`, `html`	`cli`, `html`, `json`, `junit`
フェイルファスト	`--bail`	`--on-error end` (デフォルトは最初の失敗で停止)
クラウドレポート	サインイン時に結果を自動送信	`--upload-report` でオプトイン
ベース	Newman	Apidog独自のエンジン

この表から2つの点が際立っています。第一に、両方のランナーは、環境選択、データ駆動イテレーション、重要な4つのレポート形式、そして失敗時のゼロ以外の終了コードという、CIの必須項目をほぼ同じ形でカバーしています。不適切なマージ時に失敗を示す（赤くなる）ランナーが必要なだけであれば、どちらもその役割を果たします。第二に、本当の分かれ道は、テストがどこに存在し、どのように作成されたかです。Postman CLIは、Postmanワークスペースにあるコレクションを実行します。Apidog CLIは、Apidogプロジェクトにあるビジュアルシナリオを実行します。

レポーターと終了コード：CIが実際に読み取る部分

ランナーは、書き込むレポートと返す終了コードという2つの挙動を通じて、パイプラインにおける価値を証明します。この2つが正しければ、あとは設定するだけです。

Postman CLIはコンマ区切りのレポーターリストを受け取り、サインインしている場合は結果をPostmanクラウドにも送ります。

postman collection run $POSTMAN_COLLECTION_ID \
  -e $POSTMAN_ENV_ID \
  --reporters cli,junit \
  --bail

junitレポーターは、CIダッシュボードが合否ツリーに解析するものです。--bailフラグは、最初の失敗したリクエスト、テスト、またはアサーションで実行を停止するため、スモークテストでのフィードバックを迅速に保ちます。--bailを省略するとすべて実行され、すべての失敗をまとめて報告します。CLIは何らかの失敗があった場合にゼロ以外の終了コードで終了するため、ビルドはそれ自体で失敗（赤色）になります。

Apidog CLIも同じ-rレポーターの考え方を使用し、すべてのレポートを1つの出力ディレクトリに書き込みます。

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 \
  -r html,junit --out-dir ./apidog-reports

その--on-errorフラグはシナリオ実行中の挙動を制御します。endは最初の失敗で停止し、これがデフォルトです。continueはすべてのステップを実行するため、すべての失敗を1つのレポートに収集できます。ignoreは既知の不安定なステップをスキップして、実行を中断させずに続行します。いずれにせよ、何らかの失敗があった場合、プロセスはゼロ以外の値で終了し、JUnit XMLは./apidog-reportsに生成され、ダッシュボードが取得できるようになります。

実用的な結果として、両方ともJUnit XMLを書き出し、両方とも正しくビルドを失敗させ、両方とも後で開くことができるHTMLレポートをアーカイブします。レポートにおける違いは、クラウドへの往復です。Postmanは、認証されている場合、デフォルトで結果をクラウドにプッシュします。Apidogは、アップロードを指示しない限り、レポートをローカルに保持します。どちらも抽象的には優劣はありません。一方は、意識することなくホストされた履歴を望むチームに適しており、もう一方は、ランナーから何が送られるかを正確に決めたいチームに適しています。

GitHub Actionsへの組み込み

GitHub Actionsジョブの形式はどちらも同じです。リポジトリをチェックアウトし、Nodeを設定し、CLIをインストールし、テストを実行し、失敗した終了コードがマージをブロックします。シークレットはリポジトリ設定に保存し、ワークフローファイルには決して含めないでください。

以下はPostman CLIのバージョンです。

- name: Run API tests (Postman CLI)
  run: |
    curl -o- "https://dl-cli.pstmn.io/install/unix.sh" | sh
    postman login --with-api-key ${{ secrets.POSTMAN_API_KEY }}
    postman collection run $POSTMAN_COLLECTION_ID -e $POSTMAN_ENV_ID --reporters cli,junit --bail

そしてApidog CLIのバージョンです。

- name: Run API tests (Apidog CLI)
  run: |
    npm install -g apidog-cli
    apidog run --access-token ${{ secrets.APIDOG_ACCESS_TOKEN }} -t 605067 -e 1629989 -r cli,junit

どちらも短く、読みやすく、パイプラインが関心を持つレベルで同じように動作します。成功した実行はゼロで終了しマージが進み、失敗した実行はゼロ以外で終了しマージがブロックされます。GitHubワークフローでのAPIテスト実行の詳細な手順については、GitHub ActionsでのAPIテスト自動化でステップバイステップで説明しています。Jenkinsユーザー向けには、Apidog自動テストとJenkinsのCI/CD統合で同じ考え方が示されています。

では、CIではどちらが勝者となるでしょうか？

単一の勝者はいません。なぜなら、正しい答えは、テストがすでにどこに存在し、チームがそれらをどのように作成し保存したいかによって異なるからです。

Apidog CLIが優れているのは、ホストされたクラウド履歴よりもビジュアルなテスト作成と単一の信頼できる情報源を重視する場合です。ビジュアルエディタで一度シナリオを構築すると、リクエストの連結とアサーションが自動的に処理され、同じシナリオが参照によってCIで実行されます。レポートをローカルに保持するか、アップロードするかはあなたが決定します。また、Apidogはデザイン、モック、ドキュメント作成を同じワークスペースでカバーしているため、テストシナリオは、チェック対象のAPI契約の隣に位置し、テストと仕様の乖離を防ぎます。プラットフォームをより広範に検討しているチームは、ApidogとPostmanの完全比較を読むことができます。

Postman CLIが優れているのは、チームがすでにPostmanを使用している場合です。コレクションも環境もそこにあり、何も設定せずにPostmanクラウドで実行履歴を管理したい場合に適しています。すべての実行でのクラウドへの往復は、その設定にとって非常に便利であり、ツールは公式に署名され、サポートされています。もしあなたのチームに当てはまるなら、ランナーを切り替えても得られるものは少ないでしょう。

Postmanのクラウドモデルに縛られていると感じている場合、またはテストを一度作成してどこでも実行したいだけの場合、取るべき行動は明確です。Apidogをダウンロードし、シナリオを構築し、そのCI/CDタブを開き、生成されたapidog runコマンドをパイプラインにコピーします。これがすべての設定です。

ボタン

よくある質問

Postman CLIはNewmanと同じですか？ いいえ。Newmanは古いオープンソースのnpmランナーです。Postman CLIは、Newmanを基盤として構築され、Postmanによって署名・サポートされており、Postmanクラウドへの組み込みレポート機能があります。Postman側の2つの選択肢で迷っている場合は、Postman CLI vs Newmanで違いを詳細に説明しています。

CIでいずれかのCLIを使用するためにアカウントやトークンが必要ですか？ はい、どちらも必要ですが、形式が異なります。Postman CLIは、postman login --with-api-keyを介してPostman APIキーで認証します。Apidog CLIは、--access-tokenとして渡されるアクセストークンで認証します。どちらもCIシークレットとして保存し、ワークフローファイルには決して含めないでください。

両方のランナーはテストが失敗するとビルドを失敗させますか？ はい。どちらも、テストまたはアサーションが失敗すると、ゼロ以外のステータスコードで終了します。これにより、CIシステムはビルドを赤くマークし、マージをブロックするよう指示されます。Postman CLIは最初の失敗で停止するために--bailを使用し、Apidog CLIはデフォルトである--on-error endを使用します。

レポートをクラウドに送信する代わりにローカルに保持できますか？ Apidog CLIはデフォルトでレポートをローカルに保持し、--out-dirに書き込みます。アップロードは--upload-reportを使用した場合のみです。Postman CLIもローカルレポーターを書き込みますが、サインインしている場合は実行結果も自動的にPostmanクラウドに送信します。

シナリオの正確なApidog実行コマンドはどうすれば取得できますか？ Apidogでテストシナリオを開き、そのCI/CDタブに切り替え、アクセストークンを生成すると、ApidogがシナリオIDと環境IDが事前に入力された完全なapidog runコマンドを生成します。それをコピーし、トークンをCIシークレットに移動すれば完了です。利用可能なすべてのフラグについては、apidog run --helpを実行してください。

Postmanクラウドから移行するチームはどちらを選ぶべきですか？ もし移行の理由がクラウド中心のモデルや価格設定であれば、Apidog CLIが適しています。これは、プロジェクトから単一のビジュアルシナリオを実行し、何がランナーから送られるかを決定できるためです。ランナー以外のプラットフォームがどのように比較されるかについては、ApidogとPostmanの比較から始めてください。