APIテストの進め方｜入力・応答・権限・状態を確かめる

APIテストは、APIへリクエストを送り、応答や処理結果が仕様どおりかを確かめるテストです。HTTPステータスコードが成功を示していても、返された値や保存された状態が正しいとは限りません。

入力、応答、処理後の状態を一組として考えると、何を検証したかを説明できます。本記事ではHTTPでJSONをやり取りするAPIを例に、最初のテストケースと確認内容を整理します。

ステータスコード以外に、何を確かめるのか

Postmanの公式資料には、応答本文、ステータスコード、ヘッダー、応答時間などに対する検証例があります。APIの確認は、応答が返ったかどうかだけには限りません。出典：Postman test examples

架空の注文作成APIを考えます。仕様が「注文を作成すると201を返し、作成した注文IDと数量をJSONで返す」であれば、201だけでなく、IDが存在すること、数量が入力どおりであること、必要な属性の型が正しいことを確認します。

さらに取得APIで注文を読み直し、保存された内容も確認する方法があります。応答だけ正しく、保存に失敗している問題を検出するための観点です。ただし非同期処理なら、完了を待つ条件や結果の確認方法も仕様に合わせます。

ケースは正常・入力の境界・権限から作る

以下は、数量が1〜10の整数で、認証した利用者だけが注文できるという仮の仕様に対する例です。実際の許容範囲や応答コードは、自分のAPI仕様へ置き換えてください。

エラーのケースでは、コードやメッセージだけでなく、意図しないデータ変更が起きていないかも確認します。拒否したはずの注文が保存されるなら、エラー表示だけでは十分ではありません。

同じ要求を繰り返した場合の扱いは、APIの契約によって異なります。重複防止の仕様があるならそれを検証しますが、すべてのPOSTが自動的に重複を防ぐとは考えないでください。

検証コードは、期待結果を具体的に書く

Postmanでは、応答本文をJSONとして読み、値を検証するコードを書けます。次は上記の架空APIを対象にした例です。実在のAPIへ送るためのURLや認証情報は含めていません。

pm.test("作成結果の数量を確認", function () {
  pm.response.to.have.status(201);
  const result = pm.response.json();
  pm.expect(result.quantity).to.eql(1);
  pm.expect(result.id).to.be.a("string");
  pm.expect(result.id.length).to.be.above(0);
});

コードは数量1の要求に対する応答を想定しています。任意の応答へそのまま適用して合否を判断するものではありません。IDの型が数値という仕様なら検証も変えます。実行できたことと、仕様を十分に確かめたことは区別しましょう。

データと環境をそろえて、結果を再現できるようにする

前回の注文が残っている、認証の期限が切れている、参照する商品が削除されている、といった条件でもテスト結果は変わります。開始時に必要なデータと、実施後の片付け方を決めます。

試験用アカウントやデータを使い、作成・変更・削除を伴うテストは許可された環境で行ってください。秘密情報をテストコードや共有ログへ書かず、環境設定として分けます。

失敗時の記録には、対象版、要求の条件、応答、期待結果を残します。機密情報は必要に応じて除きながら、他の人が同じ条件を確認できる内容にします。応答時間を評価する場合も、単発の測定だけで性能を決めず、負荷や測定条件をそろえる必要があります。

仕様と違ったとき、テストを直す前に理由を確認する

テストが失敗した場合は、実装の不具合、仕様変更、テストデータの不備、期待結果の誤りを切り分けます。成功させるために期待値だけを変更すると、何を保証したかったのかが失われます。

修正後は影響するケースを再実行し、必要なら関連APIも確認します。入力の境界、権限、保存状態まで確認する習慣をつけると、APIを利用する側が期待する振る舞いを具体化できます。テクノヴァースのインフラ・クラウド記事でも、システムを支える技術の考え方を紹介しています。