テスト

テストには粒度の違う種類があり、速くて安いものを多く、遅くて壊れやすいものを少なくする形をテストピラミッドと呼びます。

Web のバックエンドでは、本物の DB を使った API の結合テストが一番費用対効果がよいことが多く、ピラミッドの真ん中を厚くする考え方（テストトロフィー）もあります。スナップショットは、変化に気づく用途には便利ですが、差分を確かめずに更新しがちなので、大きなスナップショットは避けます。

Web のバックエンドで費用対効果が高いのは、本物の DB を使って API を HTTP の層から呼ぶテストです。SQL の間違い・制約・トランザクションの動きまで確かめられます。

「他人のデータは 404」「同時に2回送っても1件」のような、権限と競合のテストもこの層で書けます。

モックは、外部 API や時刻のように、テストで本物を使えないものの代わりです。何でもモックにすると、

• 実装の中身（どの関数を何回呼んだか）を確かめるテストになり、リファクタリングのたびに壊れる。
• モックと本物の動きがずれていて、テストは通るのに本番で壊れる（DB の制約・SQL の間違いはモックでは見つからない）。

DB は本物（Docker のコンテナ・テスト用の DB）を使い、モックにするのは自分で制御できない外部（決済・メール・時刻・乱数）だけにします。外部 API は MSW などで HTTP の層で置き換えると、実装に依存しにくくなります。テストは「入力に対する結果」を確かめるように書きます。

E2E テストは、本物のブラウザを動かして、ログイン・購入・登録のような大事な流れが通しで動くかを確かめます。遅くて壊れやすいので、全部の画面ではなく、壊れると困る流れに絞ります。

待ち方

不安定なテスト（たまに落ちる、flaky）の原因の多くは待ち方です。

// よくない：決まった時間だけ待つ
await page.waitForTimeout(3000);
// よい：見えるまで自動で待つ（Playwright）
await page.getByRole('button', { name: '購入する' }).click();
await expect(page.getByText('注文が完了しました')).toBeVisible();

• 固定の秒数で待たず、「要素が見える」「通信が終わる」を条件に待つ。Playwright の locator と expect は自動で待ってくれる。
• 要素は CSS のクラスより、役割とラベル（getByRole・getByLabel）で探す。見た目の変更で壊れにくく、アクセシビリティの確認にもなる。

• テストごとに必要なデータを API や DB の準備スクリプトで作り、他のテストに依存しない。順番を入れ替えても、並列に動かしても通るようにする。
• ユーザー名などに一意の値を付け、同時に動くテストとぶつからないようにする。
• ログインは毎回画面で行わず、一度ログインした状態を保存して使い回す（Playwright の storageState）。
• 外部の決済などはテスト用の環境かモックにする。

• プルリクエストごとに、プレビュー環境や CI の中で起動したアプリに対して流す。
• ブラウザのインストールをキャッシュし、テストを分割して並列で動かす（シャーディング）。
• 失敗したときのスクリーンショット・動画・トレースを成果物として残す。
• 自動のリトライは1回程度にとどめ、リトライで通ったテストは「不安定」として記録して直す。不安定なテストを放っておくと、誰も結果を信じなくなります。