品質の出口はテスト：仕様書からテストケースを書くアプローチ

概要

ryoya nagasawa さんの Zenn 記事「品質の出口はテスト。なら仕様書からテストケースで書く」へのバッジ贈呈ポスト。テスト駆動・仕様駆動の開発アプローチについて。

詳細

「品質の出口はテスト」という考え方

品質の担保は、コードレビューや静的解析だけでは不十分で、最終的にはテストが品質の出口となる。

開発フロー（一般的）:
  仕様 → 実装 → テスト → リリース

問題:
  テストは後工程 → 仕様の解釈ミスが後から発覚 → 手戻りが大きい

仕様書からテストケースを書くアプローチ

仕様書ドリブンなテスト設計:
  仕様 → テストケース設計 → 実装 → テスト実行

メリット:
  1. 仕様の曖昧さを実装前に発見できる
  2. テストが仕様のドキュメントになる（Living Documentation）
  3. 実装者とテスト設計者の認識ズレを防ぐ

実践的な流れ

1. 仕様書を読んでテストケースを列挙する
   例：「ユーザー登録 API の仕様」
   - 正常系: 有効なメールとパスワードで登録 → 201 返却
   - 異常系: 重複メール → 409 Conflict
   - 異常系: パスワードが8文字未満 → 400 Bad Request
   - 異常系: メール形式不正 → 400 Bad Request

2. テストコードを先に書く（TDD 的アプローチ）
   func TestCreateUser_DuplicateEmail(t *testing.T) {
       // 同じメールで2回登録した場合 409 が返ること
   }

3. テストが通るように実装する

4. 仕様に漏れがあればテストケースに追加 → 仕様を更新

なぜこれが重要か

仕様書だけでは「動作する仕様」を保証できない
→ テストケースに落とすことで:
  - 仕様の網羅性を確認できる
  - 境界値・エッジケースが明確になる
  - リグレッションを防ぐ安全網になる

なぜ重要か / いつ使うか

• チームで API 仕様を決めた直後にテストケースを設計するとき
• レビューで「仕様通りに動くか」を担保する基準を作るとき
• 「テストを書く文化」をチームに根付かせるための入口として