Apidog CLIとinso (Insomnia CLI) 比較：CI環境向けAPIテストランナーはどちらが最適？

パイプライン用のCLIテストランナーを選ぶのは、シンプルな質問に帰着します。それは「開発でAPIを動かしているのは何で、CIで何を自動化する必要があるか」です。チームがInsomniaを使っているなら、insoは当然の相棒です。もし、設計、モック、ドキュメント作成、テストを一つでこなせるプラットフォームが必要なら、Apidog CLIがその計算を変えます。

各ツールの概要

insoは、KongのオープンソースAPIクライアントであるInsomniaのコマンドラインコンパニオンです。リクエストコレクションの実行、ユニットテストスイートの実行、OpenAPI仕様のリンティングの3つの機能をターミナルとCIにもたらします。Insomniaデスクトップアプリが使用するのと同じデータを読み取るため、GUIでリクエストを構築すれば、insoはそれらをヘッドレスで実行します。

Apidog CLI は、設計、デバッグ、モック、ドキュメント作成、テストを単一のワークスペースでカバーするオールインワンAPIプラットフォームであるApidogのターミナルランナーです。CLIはプロジェクトからテストシナリオとコレクションを実行し、データ駆動型実行をサポートし、いくつかの形式でレポートを出力します。また、OpenAPIをインポートしたり、エンドポイント、スキーマ、ブランチなどのAPIリソースをコードとして管理することもできます。

核となる違いは、1つのテストを実行する前に現れます。insoはInsomniaエコシステムに特化したランナーとリンターです。Apidog CLIは、より広範なプラットフォームのテストサーフェスです。

Apidog CLI vs inso: 比較表

この表は要約です。以下のセクションでは、どちらかをCIに組み込む際に実際に重要な違いについて説明します。

インストール: brewとDocker vs Apidogインストーラー

insoはいくつかの公式チャンネルを通じて配布されています。一般的なものは次のとおりです。

# Homebrew
brew install inso

# Docker
docker pull kong/inso:latest

Windows、Linux、macOS用の直接ダウンロードも利用可能です。歴史的にはinsoはinsomnia-insoとしてnpmにありましたが、現在Kongが推奨しているのはHomebrew、Docker、および直接ダウンロードです。Dockerイメージは、Nodeツールチェインを管理したくないCIランナーにとって便利です。

Apidog CLIはApidogダウンロードページからインストールされ、Apidogプロジェクト内に存在するシナリオを実行します。テストはプロジェクトに紐付けられているため、CLIは手動で同期を保つ必要のあるローカルフォルダを読み取るのではなく、現在の定義をプルします。詳しい手順については、Apidog CLIインストールガイドと完全なCLIガイドをご覧ください。

各ツールの実行内容と読み込み元

これは、apidog cli vs insomnia cliの決定における最大の実際的な相違点です。

insoはスイートとスペックを名前で参照します。表示名で設計ドキュメントまたはコレクションを指定すると、作業ディレクトリ内の.insomniaディレクトリ（InsomniaのGit Syncによって作成されたもの）またはアプリがインストールされている場合はInsomniaアプリのデータディレクトリで定義を見つけます。--workingDirまたは--srcで場所を上書きできます。

inso run test "Smoke Suite" --env "CI"
inso run collection "User API" --env "Staging"
inso script seed-data --env env_staging

名前ベースのモデルは、チームが.insomniaフォルダをコミットし、それを真実の源として扱っている場合にはクリーンです。これは、CIのチェックアウトにそのフォルダが存在する必要があり、名前が安定している必要があることを意味します。

Apidog CLIは、Apidogプロジェクト内に存在するテストシナリオを実行します。ログインまたはアクセストークンで認証し、選択した環境に対してシナリオまたはコレクションを実行します。定義はプロジェクトから提供されるため、チームがGUIで構築したのと同じシナリオがCIで実行され、コミットして同期を保つ必要のあるフォルダはありません。

apidog run -t <scenario-or-collection> -e <environment>

どちらのモデルも間違っているわけではありません。insoはGitコミットされたローカルフォルダを好みます。Apidogは同期されたレコードのプロジェクトを好みます。チームがAPI定義を共有する方法に合った方を選んでください。

データ駆動型テスト

同じシナリオを多数の入力行にわたって実行する必要がある場合、これは重要です。

Apidog CLIは、CSVまたはJSONデータセットを指す-dを使用してデータ駆動型テストを直接サポートします。各行は独自の変数を持つ反復になり、1つのシナリオで数十のケースをカバーできます。

apidog run -t "Checkout Flow" -e "Staging" -d ./datasets/orders.csv

変数が列にどのようにマッピングされるかを含む完全なパターンは、Apidog CLIでのデータ駆動型テストで説明されています。

insoはその実行コマンドでデータ駆動型フラグを公開していません。環境を介してパラメーター化したり、CIジョブでinsoをスクリプト化して反復を駆動したりすることはできますが、CSV/JSONの行ごとの反復は、ApidogのようにファーストクラスのCLI機能ではありません。データセットの反復がスイートの中心である場合、それは考慮すべき真の違いです。

レポーター: 得られるもの

レポートは、CIが何が起こったかを伝える方法です。どちらのツールもアサーションの失敗時にビルドを失敗させますが、出力形式が異なります。

Apidog CLIはCLI、HTML、およびJSON形式でレポートを生成します。CLI形式は迅速なログスキャンに適しており、HTMLは共有可能な成果物を提供し、JSONはダッシュボードまたは下流のツールにフィードできます。また、--upload-reportを使用して結果をクラウドにプッシュし、ホストされたリンク可能なレポートを作成することもできます。Apidog CLIテストレポートガイドでは、各形式について説明しています。

insoはテスト結果をコンソールに出力し、終了コードを介して合否を通知します。これはほとんどのCIシステムが依拠するものです。これにより主要なニーズはカバーされます。追加のツールなしで豊富なHTML成果物やホストされたレポートが必要な場合は、Apidogがより多くの機能を提供します。

リンティング: 正直な比較

これはinsoが本当に優位に立つ点であり、そうでないと見せかけるのは不誠実でしょう。

insoはinso lint specでOpenAPIスペックをリンティングします。内部のリンターはSpectral、Stoplightの有名なOpenAPIリンターです。つまり、スタイルガイドを適用し、契約上の問題を検出し、スペックの品質に基づいてマージをゲートすることができます。これらすべてをテストを実行するのと同じCLIから行えます。

inso lint spec "Payments API"
inso export spec "Payments API" --output openapi.yaml

スペックファースト設計を実践し、CIでリントルールを適用したいチームにとって、これはinsoを選択する強力で現実的な理由です。

さて、Apidogに関する正直な比較です。Apidog CLIには、スタンドアロンのOpenAPIリンター、スタイルガイド、分割、結合、バンドルコマンドはありません。 Apidogはスペックをインポートする際に検証し、構造的な問題を検出しますが、それはインポート時の検証であり、CIでスタイルガイドに対して実行するlintコマンドではありません。ApidogのCLIがSpectralの代わりになると期待しないでください。パイプラインでの契約リンティングが必須要件であり、別のSpectralステップがない場合、insoはそれをカバーしますが、Apidogはカバーしません。

代わりにApidogがその地位を確立しているのは、統合とリソース管理であり、これが次のセクションです。

リソースとブランチ・アズ・コード

Apidog CLIはinsoができないことを実行できます。それはAPIリソースをコードとして管理することです。ターミナルからOpenAPIをインポートし、エンドポイント、スキーマ、環境、ブランチ、マージリクエストを操作できます。これにより、API設計の変更をスクリプト化し、テストを実行するのと同じ自動化に結びつけることができます。

insoはランナーとリンターとしての役割に留まります。スペックをエクスポートすることはできますが、エンドポイントを編集したりブランチを管理したりするためのリソース管理CLIではありません。

API定義とテスト実行を同じCLIで管理したいチームにとって、Apidogのリソース・アズ・コードの側面は大きな利点です。これは、inso vs apidogの選択がランナーの問題ではなく、プラットフォームの問題になることが多い理由の一部です。

プラットフォーム統合、オープンソース、価格設定

insoはオープンソースエコシステムの一部です。Insomnia自体がオープンソースであり、ツールを検査したり、セルフホストしたりしたいチームに魅力的です。正直な注意点として、計画のために言及しておくと、2023年のInsomnia 8では、反発を招いた必須のクラウド/ログインアカウントが導入され、その期間には移行やデータ損失のインシデントが発生しました。もしチームがそれらの出来事を重視するなら、Insomniaのデータ損失からの復元と移行に関する記事や、Insomniaデータを復元およびエクスポートする方法に関する記事で詳細を説明しています。しかし、CLIであるinsoがSpectralリンティングを内蔵した堅実な無料ランナーであるという事実は変わりません。

Apidogは無料枠のある商用プラットフォームです。その売りは統合です。設計、モック、ドキュメント作成、デバッグ、テストをすべて1か所で行い、CLIはそのワークスペースの自動化インターフェースとなります。別の設計ツール、モックサーバー、ランナーを組み合わせる必要はありません。Apidog vs InsomniaとInsomnia vs Apidogで、より広範な製品概要をご覧ください。最初にライブAPIに対してランナーを試したい場合は、Insomniaを使用してAPIをテストする方法とコマンドラインからREST APIをテストする方法のガイドが良い出発点です。

CIへの接続（簡潔に）

どちらのツールも同じ方法でパイプラインに組み込むことができます。インストールし、認証またはデータに接続し、実行し、終了コードでビルドをゲートします。

# CIでのinso
- run: brew install inso
- run: inso run test "Smoke Suite" --env "CI"

# CIでのApidog CLI
- run: apidog run -t "Smoke Suite" -e "CI" -r html,json

これを構築している場合は、Apidog CLI CI/CDパイプラインガイドとGitHub Actionsウォークスルーで、認証、キャッシング、レポートアップロードについて説明しています。ランナーの認証に関する詳細は、Apidog CLI認証ガイドに記載されています。

評決

唯一の勝者はいません。正直なところ、選択はチームの働き方によって分かれます。

すでにInsomniaを利用していて、.insomniaフォルダをコミットし、テストを実行するのと同じツールからCIでSpectralスペックリンティングを適用したい場合は、insoを選びましょう。オープンソースエコシステムと組み込みのリンターは真の強みであり、無料で名前参照されるランナーはInsomniaを主軸とするチームにぴったりです。

設計、モック、ドキュメント、テストを一つのプラットフォームで実現し、-dによるデータ駆動型実行、よりリッチなレポーター（CLI、HTML、JSON、およびホストされたレポート）、リソースとブランチのコード管理が必要な場合は、Apidog CLIを選びましょう。スタンドアロンのCLIリンターは失いますが、設計したものがテスト対象となる統合されたワークフローが得られます。既存のセットアップを移行するのも簡単です。inso (Insomnia CLI) からApidog CLIへの移行をご覧ください。

実際に比較してみませんか？Apidogをダウンロードして、自身のAPIに対してシナリオを実行してみてください。