APIテストはノートパソコン上ではパスするかもしれません。しかし、本当に重要なのは、人間が何もクリックすることなく、すべてのプルリクエスト、すべてのマージ、すべてのナイトリービルドでそれらが実行されるかどうかです。その役割を担うのがコマンドラインランナーです。これは、あなたがすでに作成したテストをパイプライン内でヘッドレスに実行し、クリーンなステータスコードで終了し、CIダッシュボードが読み取れるレポートを作成します。
チームがこれを設定する際、常に2つのランナーが挙げられます。Bruno CLIとApidog CLIです。これらは異なる出発点から同じ問題を解決します。BrunoはGitネイティブでオフラインファーストのオープンソースAPIクライアントであり、そのCLIはリポジトリにある.bruファイルを実行します。ApidogはオールインワンのAPIプラットフォームであり、そのCLIはアプリで作成するビジュアルテストシナリオを実行します。どちらもGitHub Actions、GitLab CI、Jenkins、およびNode.jsが動作する他のあらゆるものに接続できます。どちらもテストが失敗するとビルドを失敗させます。違いは、テストの作成方法、認証方法、およびテスト定義がCIに渡される方法に現れます。
これは、両者の正直でコマンドレベルの比較です。見せかけの議論はしません。Brunoはいくつかのことを本当にうまくこなしますし、パイプラインにどちらかを取り入れる前に、それぞれのランナーがどこにフィットするかを正確に理解できるでしょう。
要約
- Bruno CLI (
@usebruno/cli、バイナリbru) は、Gitリポジトリ内のフォルダから直接.bruファイルを実行します。オープンソースでオフラインで動作し、アカウントやトークンは不要です。ディレクトリを指定するだけで、そこにあるすべてのリクエストとアサーションを実行します。 - Apidog CLI (
apidog-cli、バイナリapidog) は、Apidogアプリで設計したテストシナリオを、アクセストークンを使用してIDでフェッチして実行します。テストをコードとして書き直す必要はなく、ビジュアルシナリオがテストであり、CLIはそれをヘッドレスに実行します。 - どちらもJUnit、JSON、HTMLレポートを出力し、テストが失敗するとビルドを失敗させます。いずれの場合も、CIダッシュボードに接続するのはJUnit XMLです。
- すべてをリポジトリ内に置き、アカウント不要で、プレーンテキストのテストファイルを完全にオフラインで管理したい場合は、Brunoを選択してください。
- ビジュアルな作成、シナリオの連結、環境管理、およびテストコードを手動で保守することなくデータ駆動型の実行を行いたい場合は、Apidogを選択してください。
実際の問題：存在するが実行されないテスト
手動で実行するテストは、腐敗するテストです。誰かがそれを作成し、一度パスした後、APIがその下で変化している間、手つかずのまま放置されます。解決策はテストを増やすことではありません。すべての変更に対して自動的に実行され、パイプラインが対処できる合否シグナルを持つテストです。
CLIランナーはそのギャップを埋めるものです。CIで役立つためには3つの要素が必要です。GUIなしで実行できること、何かが失敗したときにゼロ以外のコードで終了しビルドが赤になること、そしてレビュー担当者が何が壊れたかを確認できるよう機械可読なレポートを作成することです。BrunoとApidogはどちらもこの基準を満たしています。両者の違いは、実行コマンドよりも上流、つまりテストがどのように書かれ、どこに存在するかにあります。
CIをゼロからセットアップする場合は、CI/CDでのAPIテストの自動化における広範なパターンをこの比較と合わせて読む価値があります。ここでは、2つのランナー自体に焦点を当てます。
Bruno CLIの優れている点
Brunoの設計全体はGitネイティブです。すべてのリクエスト、環境、およびアサーションは、リポジトリ内のディスク上のプレーンテキストの.bruファイルとして存在し、他のソースファイルと同様にバージョン管理されます。このモデルには真の利点があり、比較を行う前にそれらを明確に述べる価値があります。
テストはコードと共に存在します。エンドポイントを変更するプルリクエストでは、同じ差分でそのエンドポイントのテストも変更でき、同じ人物によってレビューされます。同期すべき別のシステムはなく、リポジトリの内容から乖離する可能性のあるクラウドコピーもありません。形式がテキストであるため、差分は読みやすいです。テストをgrep検索したり、コードに使用するのと同じツールでリファクタリングしたり、エディタでマージの競合を解決したりできます。
また、オープンソースでありオフラインで動作します。CLIは、アカウント、ログイン、トークンなしで、あなたのマシンまたはCIランナー上で完全に実行されます。厳格なデータ処理ルールを持つチームや、エアギャップ環境にとっては、それが重要です。Brunoの有料ティアであるBruno Ultimateは、SSOやSCIM、シークレットマネージャー連携、監査機能などのチーム機能を追加するため、このプロジェクトは単なる趣味のツールではありません。しかし、コアクライアントとCLIは無料で自己完結型であり、それは正当な強みです。
インストールは1つのコマンドです。
npm install -g @usebruno/cli
バイナリはbruです。.bruファイルが格納されているフォルダを指し示すことでコレクションを実行します。
bru run --env staging
コレクションディレクトリ内で実行すると、bru runはそこにあるリクエストを実行します。サブフォルダを再帰的に検索してネストされたリクエストを取得するには、-rを追加します。
bru run -r --env staging
これがコアのループです。IDもトークンもリモートフェッチもありません。フォルダ内のファイルがテストであり、CLIがそれらを実行します。
私たちは、GitネイティブAPIクライアントとしてのBrunoの特徴と、大規模チームにおけるその限界について、より広範なBrunoのストーリーをカバーしました。特にCIに関しては、上記の強みが重要です。
Apidog CLIの優れている点
Apidogは、同じパイプラインに対して異なるアプローチを取ります。Apidogアプリで視覚的にテストを作成します。リクエストをシナリオに連結し、アサーションを追加し、あるレスポンスから値を次のリクエストに引き継ぎ、データファイルに対して全体をループさせます。CLIは、これらのシナリオのヘッドレスな実行者です。独自のファイル形式を持たず、ApidogプロジェクトからIDで指定されたシナリオをフェッチし、アプリが実行するのとまったく同じように実行します。
利点は、同じテストの2つの表現を誰も保守する必要がないことです。プロジェクト内のシナリオがテストそのものです。あなたは、スクリプトファイルの作成やデバッグをすることなく、リクエストの連結、変数の抽出、アサーションを処理するビジュアルビルダーでそれを記述します。そして、CLIはCIでその同じシナリオを実行します。高速な作成ループと自動化ループは、単一の真実の源を使用します。
インストールは1つのnpmコマンドです。
npm install -g apidog-cli
バイナリはapidogです。一般的な実行では、IDでシナリオを指定し、環境を選択し、アクセストークンで認証します。
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r html,junit
これらのIDを手動で入力する必要はありません。テストシナリオを開き、CI/CDタブに切り替えてアクセストークンを生成すると、ApidogがシナリオIDと環境IDをあらかじめ入力した完全なコマンドを自動で生成します。一度コピーし、その後トークンをCIシークレットに移動し、$APIDOG_ACCESS_TOKENとして参照します。すべてのオプションを一か所で確認したい場合は、Apidog CLI完全ガイドにすべてのフラグリファレンスが記載されています。
トークンベースのモデルは、Brunoとの最も明確な違いです。Apidogは、CLIがネットワーク経由で認証してアクセスするプロジェクトに保存されたテストを実行します。Brunoは、CLIがディスクから読み取るファイルとして保存されたテストを実行します。どちらも間違っているわけではなく、異なるチームのセットアップに適しています。
比較
| 項目 | Bruno CLI (bru) |
Apidog CLI (apidog) |
|---|---|---|
| パッケージ | @usebruno/cli |
apidog-cli |
| 実行コマンド | bru run |
apidog run |
| テストソース | Gitリポジトリ内の.bruファイル |
Apidogプロジェクト内のテストシナリオ (IDでフェッチ) |
| 作成方法 | テキストファイルを手動で編集、またはBrunoアプリを使用 | Apidogアプリのビジュアルシナリオビルダー |
| CIでの認証 | なし; オフラインで実行 | アクセストークン (--access-token) |
| 実行対象の選択 | フォルダパス、-r (再帰)、--tags |
-t (シナリオ)、-f (フォルダ)、--test-suite |
| 環境 | --env <name> |
-e <environmentId> |
| データ駆動型 | --csv-file-path、--json-file-path |
-d <path> (CSVまたはJSON) |
| イテレーション | --iteration-count <n> |
-n <n> |
| レポーター | JSON、JUnit、HTML | cli、html、json、junit |
| 早期失敗 | --bail |
--on-error end (デフォルトは最初のエラーで失敗) |
| オープンソース | はい | いいえ (無料のnpm CLI; プランに基づきシナリオを実行) |
| ライセンス/アカウント | CLIには不要 | プロジェクト用のApidogアカウント |
2つの点が際立っています。第一に、どちらのランナーもCIの重要な要素をカバーしています。環境選択、データ駆動型イテレーション、重要な3つのレポート形式、そして失敗時のゼロ以外の終了コードです。第二に、両者の違いは、テストがどこに存在し、どのように書かれたかであって、生の機能ではありません。Brunoはテストをリポジトリ内にテキストとして保持します。Apidogはテストをプロジェクト内にビジュアルシナリオとして保持し、参照によって実行します。
レポーターと終了コード：CIが実際に読み取る部分
ランナーがパイプラインでその役割を果たすのは、2つの挙動によってです。それは、作成するレポートと、返す終了コードです。これらが正しく行われれば、残りは配線作業に過ぎません。
Brunoは形式ごとのフラグでレポートを作成します。必要な各形式のパスを渡します。
bru run -r --env staging \
--reporter-junit ./results/junit.xml \
--reporter-html ./results/report.html \
--reporter-json ./results/report.json
JUnit XMLは、CIダッシュボードが解析して合否ツリーを生成するものです。HTMLレポートは閲覧可能な成果物となります。Brunoの--bailは、最初のリクエスト、テスト、またはアサーションの失敗後に実行を停止し、スモークテストでのフィードバックを迅速にします。--bailがない場合、すべてを実行し、すべての失敗を一度に報告します。
Apidogはカンマ区切りのリストを持つ単一の-rフラグを使用し、すべてを1つの出力ディレクトリに書き出します。
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 \
-r html,junit --out-dir ./apidog-reports
その--on-errorフラグは、シナリオ途中の挙動を決定します。endは最初のエラーで停止し（デフォルト）、continueはすべてのステップを実行してすべての失敗を1つのレポートにまとめ、ignoreは既知の不安定なステップをスキップします。いずれの場合も、何かが失敗すれば実行はゼロ以外の終了コードで終了します。
終了コードの規約は両者で同じであり、それが最も重要な部分です。アサーションが失敗すると、ランナーはゼロ以外のコードで終了します。CIはそのコードを読み取り、ステップを失敗とマークし、ジョブを失敗させ、マージやデプロイをブロックします。追加の設定は不要です。両者に共通する唯一の落とし穴は、終了コードを飲み込んでしまうことです。もし実行をシェルパイプラインでラップしたり、|| trueを追加したりすると、ゼロ以外の終了コードが消滅し、ゲートがサイレントに機能しなくなります。そのようなことはしないでください。
GitHub ActionsにおけるBruno CLI
.bruファイルはすでにリポジトリにあるため、ワークフローは短いです。コードをチェックアウトし、CLIをインストールし、コレクションを実行し、レポートをアップロードします。
name: API tests
on:
pull_request:
branches: [main]
jobs:
api-tests:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install Bruno CLI
run: npm install -g @usebruno/cli
- name: Run API tests
working-directory: ./api-tests
run: bru run -r --env staging --reporter-junit ./results/junit.xml
- name: Upload report
if: always()
uses: actions/upload-artifact@v4
with:
name: bruno-report
path: ./api-tests/results
working-directoryはコレクションを格納しているフォルダを指します。if: always()は、テストが失敗した場合でもレポートのアップロードを継続させます。これはレポートを読みたいまさにその時です。リモートサービスへの認証は行われないため、シークレットは不要です。
GitHub ActionsにおけるApidog CLI
Apidogのワークフローは構造的には同じですが、1点追加があります。アクセストークンはリポジトリのシークレットから取得され、シナリオはフォルダパスではなくIDで選択します。
name: API tests
on:
pull_request:
branches: [main]
jobs:
api-tests:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install Apidog CLI
run: npm install -g apidog-cli
- name: Run API test scenario
run: |
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t 605067 \
-e 1629989 \
-r html,junit \
--out-dir ./apidog-reports
env:
APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
- name: Upload report
if: always()
uses: actions/upload-artifact@v4
with:
name: apidog-report
path: ./apidog-reports
対称性に注目してください。同じチェックアウト、同じNodeセットアップ、同じインストール後に実行の形式、同じ常時アップロードです。唯一の本当の違いは、シークレットとして設定されるトークンと、IDで選択されるシナリオです。GitLab CIやJenkinsのバリアントでもこれを拡張したい場合は、Apidog CLI完全ガイドが、これらのランナー全体で同じパターンを説明しています。
選択方法
どちらのランナーが「より優れているか」という決定になることはほとんどありません。重要なのは、チームがどのようにテストを作成し、保存したいかです。
リポジトリが真実の源である場合にBrunoを選択してください。 コードと共に存在するプレーンテキストファイルとしてすべてのテストを管理し、同じプルリクエストでレビューされ、実行時にアカウントやネットワーク呼び出しが不要な場合、Brunoはそのモデルに完全に適合します。テストをコードとして扱い、オフラインおよびオープンソースツールを重視し、.bruファイルを直接編集することに抵抗がないチームにとって、自然な選択肢です。後でチームとガバナンス層が必要になった場合、Bruno UltimateはSSO、SCIM、シークレットマネージャー統合、監査機能を追加するため、将来的に導入する選択肢があり、障壁にはなりません。
ファイルレベルの制御よりも作成速度と統合されたワークフローが重要である場合にApidogを選択してください。 テストコードを手動で記述してデバッグすることなく、テストシナリオを視覚的に構築し、リクエストを連結し、変数を抽出し、同じシナリオを複数の環境で実行したい場合、Apidogのモデルはその摩擦を取り除きます。設計、デバッグ、モック、テストが1つのワークスペースで完結し、CLIは作成した正確なシナリオを実行します。Postmanのセットアップから移行するチームにとって、そのメンタルモデルはきれいに適合し、ApidogはAPIテスト用のPostman代替として移行パスをカバーします。
両方のツールを使用するという答えもあります。一部のチームは、低レベルのリクエストチェックにはBrunoのGitネイティブファイルを保持し、より大規模な連結シナリオや環境に依存する回帰テストにはApidogを使用します。2つのCLIは1つのパイプラインで問題なく共存できます。それぞれが独立したステップであり、独立した終了コードを持ちます。
もしCLIだけでなく、より広範なプラットフォーム間で迷っているのであれば、ApidogとBrunoの比較では、コマンドラインを超えた設計、モック、コラボレーションについて説明しています。最初の自動化シナリオをセットアップし、同日午後にターミナルから実行するには、Apidogをダウンロードし、任意のシナリオのCI/CDタブから生成されたコマンドをコピーしてください。
よくある質問
Bruno CLIは無料ですか？
はい、無料です。Bruno CLIはオープンソースで、@usebruno/cli npmパッケージとして提供されています。アカウントやトークンなしで、あなたのマシンまたはCIランナー上で完全に動作します。Bruno Ultimateは、SSO、SCIM、シークレットマネージャー連携、監査などのチームおよびガバナンス機能を追加する有料ティアですが、CLI自体は無料です。
Apidog CLIは無料ですか？
CLIは無料のnpmパッケージapidog-cliです。Apidogプロジェクトのテストシナリオを実行するため、実行できる内容はApidogプランに依存しますが、コマンドラインランナーは別途有料の製品ではありません。
どちらのランナーでもテストをコードとして記述する必要がありますか？
Brunoの場合、テストは手動で編集したりBrunoアプリで作成したりできる.bruファイルであるため、直接触れるテキスト形式があります。Apidogの場合、アプリ内で視覚的にシナリオを構築し、CLIがIDで実行するため、テストコードを手動で保守する必要はありません。これが両者の主要な作成方法の違いです。
両方のランナーは、テストが失敗した場合にビルドを失敗させますか？
はい。どちらもアサーションが失敗するとゼロ以外のコードで終了します。CIはそのコードを読み取り、ステップを失敗とマークし、マージやデプロイをブロックします。Brunoの--bailは最初のエラーで停止し、Apidogの--on-error endも同様でデフォルト設定です。|| trueで実行を囲むことは避けてください。これは終了コードを飲み込み、ゲートを機能しなくします。
CIではどのレポート形式を使用すべきですか？
CIダッシュボードが解析して合否ツリーを生成する機械可読な結果にはJUnit XMLを使用し、閲覧可能な成果物が欲しい場合はHTMLを追加してください。Brunoは--reporter-junitと--reporter-htmlでそれらを書き込みます。Apidogは-r html,junitを使用します。どちらもカスタム後処理のためにJSONもサポートしています。
Bruno CLIの実行にはインターネット接続やアカウントが必要ですか？
いいえ、必要ありません。Brunoはリポジトリ内の.bruファイルをローカルで実行し、ログインやリモートからのフェッチは行いません。そのため、オフラインまたはエアギャップされたCIに適しています。ApidogのCLIはアクセストークンで認証し、プロジェクトからシナリオをフェッチするため、実行時にApidogサービスへのネットワークアクセスが必要です。
どちらのCLIもグローバルインストールなしで実行できますか？
はい、両方とも可能です。永続的なグローバルインストールなしで実行するには、npx @usebruno/cli run ... または npx apidog-cli run ... を使用します。これは一時的なCIランナーで便利です。インストールされているバージョンで利用可能な正確なオプションを確認するには、bru run --help または apidog run --help を実行してください。