テスト

テスト戦略

統合テストと E2E テストの2層を基本とし、複雑なロジックに限ってユニットテストを補う。統合テストでバックエンドの入出力と永続化をまとめて検証し、E2E テストで利用者の操作フローを検証する。この2層で、実際に利用者へ届く挙動を最小の重複で担保する。

ユニットテストを基本に据えないのは、実行は速い一方で対象が狭く、層をまたいだ結合の不具合を捉えられないためである。統合テストと E2E テストは実行コストが高いので、複雑な分岐やエッジケースだけをコストの低いユニットテストへ切り出し、同じ範囲を二重には検証しない。

統合テスト

バックエンドの全層（API → UseCase → Domain → Infrastructure）を通して、API の入出力とデータの永続化を検証する。

検証する対象は次のとおりである。

• 各エンドポイントの正常系で、期待するデータが返る。
• 異常系のドメインエラーパス（NOT_FOUND・CONFLICT など）が返る。
• 作成・更新・削除の結果が、データベースへ正しく永続化される。
• 未認証で 401、権限不足で 403 を返す（認証・認可）。

一方、次は統合テストでは検証しない。入力バリデーションは Valibot スキーマが保証するため、ここで再検証すると二重チェックになる。Infrastructure 層の内部実装は、SQL やドライバの挙動をライブラリが保証するため対象外とする。ビジネスロジックの全エッジケースは、実行コストの低いユニットテストへ委ねる。

E2E テスト

ブラウザを通じて、利用者の操作フローが正しく動くことを検証する。

検証する対象は次のとおりである。

• 主要な操作フロー（壊れると事業に直接影響する操作）を通す。
• 画面遷移（リンク、フォーム送信後のリダイレクト）が正しく行われる。
• フォーム操作が完了し、結果が画面へ反映される。
• エラー時に、利用者へのフィードバックが表示される（代表的なケースを1つ）。

網羅的なエッジケースや異常系の全パターンは E2E では検証しない。実行コストが最も高いため、ロジックの網羅は統合テストが担う。API レスポンスの構造や値の詳細も統合テストで検証済みであり、E2E では代表的なエラー表示の確認にとどめる。スタイリングやレイアウトの詳細は範囲外とし、ビジュアルリグレッションツールへ委ねる。

ユニットテスト

純粋関数や複雑なビジネスロジックを、依存なしに高速へ検証する。統合テストではカバーしづらい複雑な分岐やエッジケース（複数条件の組み合わせによる計算、日付範囲の重複判定、状態遷移など）に限って書く。

検証する対象は次のとおりである。

• 入力に対する出力が正しい。
• 境界値・エッジケース（0、負数、空配列、null など）で正しく振る舞う。
• エラーパス（不正な入力に対する例外やエラー値）を返す。

単純な getter/setter やパススルー関数は、ロジックを持たず信頼性が上がらないため検証しない。実装の詳細も、リファクタでテストが壊れる原因になるため避け、振る舞いだけを検証する。外部ライブラリの動作はライブラリ側で保証されるため対象外とする。

関連項目

• テスト名の付け方 — テスト名の形式と例