第1部：Postmanによる API テストと開発は本来何のためのものか
コレクションとは、共有でき、実行できるリクエストの記録です。そのため、次の3つの仕事に非常に向いています。よく知らない API を探索すること、実際に実行できるサンプル付きでドキュメント化すること、そして相手がそのまま実行できる再現手順を渡すことです。この3つはきちんと取り組む価値があり、しばしば過小評価されています。
チームが誤るのは、コレクションを使うこと自体ではありません。ほかに何も変えないまま、コレクションをそのままリグレッションスイートにできると考えてしまう点です。
第2部：4つの問題
どのツールで組んだ API テストスイートも、最終的には同じ4つにぶつかります。これらをあらかじめ知っていることが、スキルの大部分を占めます。
セッションは期限切れになる
実行の途中でトークンが失効し、その失敗がプロダクトのバグのように見えます。
認証情報は個々のリクエストから切り離し、環境側で管理します。
値は呼び出しをまたいで受け渡される
作成系のリクエストは、次の呼び出しが必要とする識別子を返します。
その値は取得して使い、決してハードコードしないでください。さもないと、スイートは一度しか動きません。
順序が意味を持つ
カバレッジはグラフであり、コレクションはリストです。
序盤の失敗がひとつあるだけで、無関係な赤い失敗が画面いっぱいに連鎖します。
4つ目はクリーンアップです。レコードが積み上がり、一意性制約に引っかかり始め、ページネーションのアサーションがずれていきます。名前のパターンで削除する方法は、2つの実行が重なるまでは安全です。
第3部：書く価値のあるアサーション
ステータスだけでなく、ボディを検証します。 本来レコードがあるはずの場所で空のリストを返す 200 は、ステータスの確認だけでは合格と判定されてしまうバグです。
失敗が正しく失敗することを検証します。 存在しないものをリクエストし、ステータスコードとエラーの形式を確認します。エラーを中身に含めたまま 200 を返すサービスは珍しくありません。
エンドポイントをまたいで検証します。 あるレコードが別のレコードを参照しているなら、そちらも取得します。興味深いバグは、2つの呼び出しのあいだに潜んでいます。
第4部：コレクションでは足りなくなるとき
その兆候は、pre-request スクリプトが一人しか理解できない小さなフレームワークになってしまうことです。そうなった時点で、4つの問題はツール側ではなく自分たちのインフラの問題になっています。そこが、リグレッションのカバレッジを、これらを製品の一部として扱う場所へ移すタイミングです。TestSprite はこれらを Auto-Authentication、Dynamic Variables、Dependency Chains、Auto-Cleanup として扱います。詳しくはこちらをご覧ください： API テストのドキュメント。
コレクションは残しておきましょう。探索とドキュメント化には、いまでもコレクションが最適です。
第4.5部：誰もレビューしないスクリプト
コレクションの中にある pre-request スクリプトとテストスクリプトには、少し目を向ける価値があります。興味深い失敗はそこに潜んでいるのに、ほとんどレビューされないからです。
これらは JavaScript であり、決まった順序で実行され、共有された環境変数を書き換え、差分が読み取りにくい JSON のエクスポートの中に保存されています。トークン更新スクリプトを一か所変えただけで40件のリクエストが壊れることもあるのに、プルリクエストに表示されるのは JSON が1行変わったという情報だけです。チームがこれに気づくのは、同じ週に2人がコレクションを編集した最初のときです。
前の段落に心当たりがあるところまでスクリプトが育っているなら、そのコレクションはすでにソフトウェアです。ソフトウェアにはレビューとバージョン管理、そしてそれ自体のテストが必要になります。別のものをテストするのが目的だったはずなのに、たどり着く場所としては奇妙です。
第5部：自分が動かさなくても回るようにする
ダッシュボードからリポジトリを接続すれば、すでに作成しているデプロイを起点に実行が始まります。あるいは、自分のワークフローにステップを追加する方法もあります。
ターミナル
npm install -g @testsprite/testsprite-cli
testsprite setup
ローカルに何もインストールしたくない場合は、TestSprite のダッシュボードから同じ設定を行えます。CLI のそのほかの機能はこちらにまとめています： CLI リポジトリ。
第6部：TestSprite は4つの問題をどう扱うか
4つにはそれぞれ名前が付いており、利用者が書くスクリプトではなく製品の機能として扱われます。Auto-Authentication はログインフローを一度設定しておけば、実行のたびに新しいトークンを取得します。Dynamic Variables はあるレスポンスから値を取得し、次のリクエストに差し込みます。Dependency Chains は、各テストケースが必要とするものと生成するものから安全な実行順序を導き出します。Auto-Cleanup は、その実行で作成されたレコードだけを削除します。
カバレッジは、稼働中のサービスと手元にある仕様書をもとにした API Discovery から始まります。生成されるテスト計画には、認可、エラー処理、境界値という、人が飛ばしがちなカテゴリが含まれます。
コレクションを通じてこの分野を学んできた人にとっての利点はこうです。コレクションは最も得意とする探索とドキュメント化のために残しつつ、リグレッションスイートは一人で保守する JavaScript の塊ではなくなります。
公式の無料 PDF はありますか？
それは出版社が決めることであり、状況も変わります。このページは書籍の写しではなく、実務で効く知識をまとめたものです。
まず Postman から学ぶべきですか？
はい。API の正確なメンタルモデルを作る最短の方法であり、そこで得た理解はほかのどのツールにも応用できます。
スクリプトも習得する必要がありますか？
読める程度で十分です。大量に書くようになったら、それはリグレッションスイートとしてのコレクションを卒業したという合図です。
どの順番で学べばよいですか？
まずリクエストを送り、次にボディを検証し、続いて認証を扱い、呼び出しを連鎖させ、最後にクリーンアップします。多くの人が手前でやめてしまう最後の2つにこそ、価値があります。
CI には Newman で十分ですか？
CI でコレクションを実行する分には問題ありません。問題は、どのランナーが実行するかではなく、その下にあるスクリプトを誰が保守するかです。