API と DB のテスト

画面を通さずに API を直接テストすると、速く・細かく確かめられます。画面では選べない値（マイナスの数、とても長い文字列、他人の ID）を送れるのも利点です。

curl と Postman

curl はコマンドで HTTP のリクエストを送る道具で、手順をそのまま共有できます。

curl -i -X POST https://staging.example.com/api/orders \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"item_id": 1, "quantity": -1}'
# -i でステータスとヘッダーも表示。期待は 400 か 422

Postman などの GUI の道具は、リクエストをまとめて保存し、環境（開発・検証）ごとの変数を切り替え、レスポンスの確認（ステータスが 201 か、項目があるか）を書いて連続で流せます。

API は、リクエストを受け取ってから、形の検査・認証・権限・処理の順に進みます。段ごとに「通すべきもの」と「止めるべきもの」を送ると、観点の抜けが減ります。

通信が切れて再送されたり、ボタンを二度押したりすると、同じリクエストが2回届きます。何回送っても結果が1回分と同じになる性質を冪等性（べきとうせい）と呼びます。注文・支払いのように二重になると困る処理で、必ず確かめる観点です。

どう防ぐかは設計しだい（冪等キー、DB の一意制約、状態の確認）なので、まず開発者に「2回届いたらどうなる設計か」を聞き、その期待結果でテストします。

契約テストは、API を提供する側と使う側が「この形でやり取りする」という約束（契約）を守っているかを確かめるテストです。OpenAPI などで書いた仕様とレスポンスの形が一致するかを自動で検査したり、Pact のような道具で「使う側が期待する形」を契約ファイルにして、提供側の CI で実際の API に流して確かめたりします（利用者主導の契約テスト）。全体をつないだ E2E テストより速く、「項目名を変えたら別のサービスが壊れた」といった不具合を早く見つけられます。

画面に「登録しました」と出ても、データが正しく保存されたとは限りません。QA は DB を直接見て、保存された値・件数・関連するデータを確かめられると強いです。必ず検証用の環境で、読み取り専用のアカウントを使います。

SELECT で確かめる

-- 注文したデータが正しく保存されたか
SELECT id, user_id, status, total, created_at
  FROM orders
 WHERE user_id = 123
 ORDER BY created_at DESC
 LIMIT 5;

-- 明細の合計と注文の合計が一致するか
SELECT o.id, o.total, SUM(i.price * i.quantity) AS items_total
  FROM orders o JOIN order_items i ON i.order_id = o.id
 GROUP BY o.id, o.total
HAVING o.total <> SUM(i.price * i.quantity);

下のラボで、本物の DB を使って SELECT を練習できます。

DB を見るときは、画面ではずれが見えにくい次の観点を意識します。

特に日時は、保存は UTC、表示は日本時間、という作りが多く、日付が変わる前後（日本時間の 0 時＝UTC の 15 時）のデータで集計や表示がずれる不具合がよく見つかります。

テストの結果がばらつく原因の多くはデータです。誰がいつ流しても同じ状態から始められるように、データの作り方と後片付けを決めておきます。

• 再現できる形で用意する：SQL のスクリプトや API・シードの仕組みで作り、誰がいつ流しても同じ状態にする。手で作ったデータは消えると再現できません。
• 境界のデータも作る：0 件・1 件・とても多い件数、期限ちょうど、長い名前など。
• テストごとに独立させる：自動テストでは、テストごとに専用のユーザーやデータを作り、他のテストの結果に左右されないようにする。
• 本番のデータをそのまま使わない：個人情報が含まれるので、使う場合は匿名化（マスキング）したものにする。