先に結論
-
Postmanが適しているのは APIを探索する、ドキュメント化する、あるいはテストコードを書かない人と再現可能なリクエストを共有する場合です。
-
TestSpriteが適しているのは サービスが実際に公開しているものからAPIカバレッジを生成し、セッション、状態、順序、クリーンアップを製品機能として扱ってほしい場合です。
-
両方を併用すべきなのは コレクションが実際に役割を果たしている場合です。探索とドキュメントのためにコレクションを残し、リグレッションは生成されたカバレッジに任せてください。
並べて比較
| 観点 | Postman | TestSprite |
|---|---|---|
| 主な強み | リクエストの探索、ドキュメント化、共有 | サービスが公開しているもののカバレッジの生成と維持 |
| カバレッジの作り方 | 誰かが各リクエストを追加し、スクリプトでアサーションを書く | 仕様または探索パスから生成し、その後に調整する |
| セッションの扱い | 自分で書いて保守するPre-requestスクリプト | Auto-Authentication、設定は一度だけ |
| 呼び出し間で受け渡す値 | スクリプトで設定する環境変数 | Dynamic Variables、レスポンスから自動で連携 |
| 実行順序 | コレクションの並び順を手作業で管理 | 各テストが必要とするものと生成するものから導出 |
| クリーンアップ | スクリプトに書いた分だけ | 実行によって作成されたものに連動するAuto-Cleanup |
| 適した用途 | 探索、ドキュメント、手動での確認 | 専任QAなしでの広範なリグレッション |
この4つの仕組みの詳細は、次のドキュメントで説明しています: APIテストのドキュメント。
Postmanが本当に優れている領域
よく知らないAPIを探索するとき。 エンドポイントが何をするのかを学んでいる段階では、手作業で叩いてみることに勝る方法はありません。
再現手順を共有するとき。 インポートしてそのまま実行できるコレクションは、APIチームが受け取れる最も分かりやすいバグ報告です。
生きたドキュメント。 サンプルを兼ねたリクエストを、説明対象のAPIのすぐそばに置いておけます。
スクリプト化されたコレクションのコストが膨らむところ
本格的に使われるコレクションは、いずれトークンを扱い、識別子を取り出し、順序を守らせ、後始末をするPre-requestスクリプトとテストスクリプトの塊を抱えることになります。それは実質的にJavaScriptで書かれた小さなフレームワークであり、フレームワークとして設計されていないツールの中に埋め込まれ、たいていは一人しか理解していません。
それでも動きはします。代償は、その仕組みを理解している人自身が依存先になってしまうことです。そしてコレクションが赤くなったとき、直されるのではなく隔離されてしまいます。
コレクションがドキュメントそのものである場合
生成されたスイートでは置き換えられない役割をコレクションが担っているケースがあります。その場合は、統合して手放すのではなく、守る価値があります。
外部の利用者があなたのAPIを学ぶためにインポートするものがそのコレクションなら、それは実行ボタンの付いたドキュメントであり、その価値は初めて見る人にも読めることにあります。だとすれば、小さく、厳選され、サンプル中心に保つべきだということになります。これはリグレッションスイートに求められるものとは正反対です。スクリプトによるセットアップを伴い、400件のリクエストにまで膨れ上がったコレクションは、もはやその目的を果たしておらず、おそらくしばらく前から果たせていません。
きれいな切り分け方は、コレクションを入口とし、安全網の役割は別のものに任せることです。この2つは互いに逆方向へ引っ張り合うため、1つの成果物に両方を担わせようとすることこそが、多くのコレクションが読みやすくも信頼できるものにもならずに終わる理由です。
両方を併用する
コレクションは探索、ドキュメント、再現手順のために残してください。動き続ける必要があるエンドポイントや統合の連鎖は、生成されたカバレッジに任せます。両者は答えようとしている問いが違うため、実際にはほとんど重なりません。
評価するなら、わざと何かを壊してみる
保存ボタンを押しても保存されなくなる、といった実際のリグレッションを仕込み、それぞれのツールが何を報告するかを見てください。問いは3つです。テストは失敗するか。その失敗は実際のズレを言い当てているか。そして、修正する人やエージェントは、その出力から経緯を自力で再構成せずに着手できるか。アサーションにたどり着かなかった実行を成功として報告するツールは、唯一重要なテストに落ちています。
ダッシュボードからリポジトリを接続すると、すでに生成しているデプロイを起点に実行が始まります。あるいは、自分のワークフローにステップを追加する方法もあります。どちらの手順も次で説明しています: CLIリポジトリ。
コレクションに背負わせるべきでないものをTestSpriteが引き受ける
広範なリグレッションを、状態にまつわる4つの問題を製品機能として扱いながら提供します。セッションにはAuto-Authentication、実行時にしか存在しない値にはDynamic Variables、順序にはDependency Chains、実行が作成したものにはAuto-Cleanupです。コレクションをスクリプト開発プロジェクトに変えてしまうのは、まさにこれらの要素です。
カバレッジは、稼働中のサービスに対するAPI Discoveryと手元の仕様から生成されます。これにより、手作業で作ったコレクションでは飛ばされがちなエラーパスや境界値のケースが得られます。調整はPre-requestスクリプトではなく、普通の言葉で行います。
その結果、コレクションは本来最も得意とすること、つまり探索し、ドキュメント化し、インポートしてそのまま実行できる再現手順を誰かに渡すことに戻れます。トークン更新スクリプトを理解している唯一の人になる必要は、誰にもありません。
既存のコレクションをインポートできますか?
既存のコレクションは、移行すべきテストとしてではなく、何が存在するかを示す仕様として扱ってください。役に立つのはエンドポイントの一覧です。
CIにはNewmanで十分ですか?
NewmanはCI上でコレクションを問題なく実行します。問われているのはランナーではなく、セッション、状態、順序、クリーンアップを扱うスクリプトを誰が保守するのかという点です。
Postmanのモニターはどうですか?
稼働監視や単純な契約チェックには向いています。ただし、呼び出し間の依存関係を理解したカバレッジの代わりにはなりません。
ドキュメントは失われますか?
いいえ。ここで述べたものはどれも、ドキュメントとしての役割を置き換えるものではありません。それはPostmanが本当に得意とすることの1つです。
初日にどれくらいのカバレッジが得られますか?
探索パスと仕様を組み合わせると、API全体にわたる計画が生成されます。何かを実行する前に内容を確認し、管理用や内部向けのルートを外してください。