テストを書く前に「あるべき挙動」を書くと設計が楽になる
テスト設計の前に仕様レイヤーを挟むTRSで、漏れが見え、81本の受け入れ基準から360件のテストを自動生成できた実践報告。
#なぜ今日これを選んだか
実装漏れは「書き忘れ」ではなく「そもそも決まっていなかった」ことから起きる場合が多い。この記事は、テストを書く前に振る舞いを正常・準正常・例外の3つに分けて書き出すだけで、漏れと意図的な除外を区別できると示している。品質を守りではなく設計で上げる、という視点に直結する。
#要点
- TRS（テスト要求仕様）は2層構造。仕様レイヤーで振る舞いを確定し、テスト設計レイヤーで確かめ方を決める
- ユーザーストーリー → ユースケース → 振る舞い分類（正常・準正常・例外）で階層化し、受け入れ基準はGherkin形式で具体値を抜いて書く。可変データは因子一覧表、未決事項は Open Issues に分ける
- 81本の受け入れ基準から360件のテストケースを自動生成。人の仕事が「書く」から「レビューする」に移った
#自分にとっての示唆
AIにコードを書かせるほど、「何が正しい挙動か」を人間が先に決めておく価値は上がる。受け入れ基準が曖昧なままAIに渡すと、もっともらしい実装が漏れごと出てくるだけだ。いま作っている可動域の記録アプリでも、測定の正常・準正常（姿勢が少し崩れた）・例外（関節が画面外）を先に3つの枠で書き出し、Open Issues を残す形にしたい。明日からは、機能を1つ足す前に受け入れ基準を3行書き、それをAIに渡してテストを先に作らせる。書く役と確かめる役を分けることが、品質を上げる一番安い手だと思う。