| name | test-extract |
| description | test-design の 0 段(振る舞い抽出)。対象(機能、モジュール、API、PR 差分)から「テストすべき振る舞い」を T-ID 採番チェックリスト台帳(tasks/test-design/<対象名>.md)へ網羅的に出し切る。 「テストすべき振る舞いを洗い出して」「テスト観点を出して」「T-ID 台帳」と言われたとき、 または test-design ルーターから 0 段として委譲されたときに使用する。既存テストのレビューでも 最初にこの台帳を作る(台帳を両向きに読んで抜け・根拠なしテストを見つける)。 後続の test-catalog(手法選定)はこの台帳が完成(全 T-ID `[x]`・欠番なし)してからでないと進めない。 通常は test-design ルーター経由で使う。
|
test-extract (0 段: テストすべき振る舞いの網羅抽出)
いきなりテストを書かない。 対象から「テストすべき振る舞い」を網羅的に出し切る工程を先に置く。
姉妹スキル loopeng-extract(loop-engineering の 0 段)と同じ思想で、漏れはこの入口に落ちる。
原則は 過剰抽出は安全、漏れは危険。迷ったら採り、後で優先度で落とす。
loopeng-gherkin 由来の .feature があるとき(先に転記する)
tasks/loopeng/ に <Name>.feature があれば、通常抽出の前にまずこれを転記する。
シナリオ1件=T-ID 1行。Given/When/Then の正常系シナリオは event/state、反例由来のシナリオは unwanted として起こす。
出典欄に <Name>.feature と書く(test-design-extract-gate hook がこの文字列で転記済みかを機械判定する)。
転記が済んでいないと、この後の実装テストの Write/Edit が hook でブロックされる。
手順
- 曖昧な用語と暗黙の要求を先に定義する: 抽出の前に、対象に出てくる語の意味を一つずつ確定させる。「翌営業日」なら「営業日とは? 休日とは(日曜、指定土曜、祝日)? 月跨ぎは?」まで割る。語の定義が曖昧なまま振る舞いを出すと、境界(連休、月末)と異常系がそっくり抜ける。用語の未定義は最大の抽出漏れ源。併せて「当たり前要求」(セキュリティ、実行効率、法令)など暗黙のニーズも、非機能の種別として明示に引き上げる。
- 走査アンカーを選ぶ: 対象の構造単位を決める。受け入れ条件、関数シグネチャ、コードの分岐、状態遷移、API エンドポイント×メソッド、不変条件のいずれかを使う。仕様視点(ブラックボックス)とコード視点(ホワイトボックス)で独立に出して union を取ると漏れにくい。
- 採番チェックリスト台帳に落とす:
assets/test-extract-template.md を tasks/test-design/<対象名>.md(この場所に固定。test-design-extract-gate hook が検査する場所)にコピーし、振る舞いごとに T-001 から連番で1行立てる。頭の中で済ませない。
- 各振る舞いに種別を振る: テンプレートの EARS 5類型ラベル(
event/state/ubiquitous/unwanted/optional、境界は boundary、非機能は nonfunctional)のいずれかを振る。この型ラベルは loop-engineering の EARS と共通で、TLA+ を使わない通常のタスクでも「正常系に対応する異常系を出したか」を書式として強制する軽量版として使う。先に事前条件(対象が規定の振る舞いを保証する入力・状態の範囲)を確定させ、その内側だけを網羅対象にする。事前条件違反のうち応答を保証したい分だけを事後条件へ引き上げて unwanted に積む(契約の詳細は ../test-target-design/SKILL.md)。そのうえで各 event/state 行に「不正入力なら? 境界なら? 並行なら?」を必ず問い、unwanted の行を系統的に生やす。履歴依存があるものは「**起きてはいけない振る舞い(禁止される列)**は何か」も問う。途中まで正常で一手で初めて禁止になる列(二重支払い、期限切れ後の操作)が、ここで unwanted の行になる(導出は ../blackbox-state/SKILL.md の禁止仕様からのテスト導出)。状態遷移・並行・プロトコルがあり TLA+ の網羅検査まで要る場合は loop-engineering へ委譲する。
- 全 ID が
[x] で欠番なしになったら抽出を閉じる。未チェックが残る=抽出途中。
- 閉じた証跡を出す(必須ゲート、自己申告で済ませない): テストを1件でも書く、または次工程へ進む前に、台帳の絶対パスと、未チェック残数ゼロ・欠番なしを機械確認した出力を応答に示す。示せないなら0段は未完で、先へ進まない。
grep -cE '^\| T-' <台帳>
grep -E '^\| T-' <台帳> | grep -c '\[ \]'
grep -nE '^\| T-' <台帳>
レビュー用途のとき(台帳を両向きに読む)
既存テストを台帳の右側(テスト名)に先に埋める。
- 左側(振る舞い)に空欄が残れば、それがテストの抜けである。
- 右側(テスト)に対応する左側が無ければ、それは根拠を説明できないテストで、対象外の振る舞いを縛る脆さか、抽出漏れ(立て損ねた振る舞い)のどちらかを疑う。
- 手法が実装詳細に密結合していれば、それが脆さである。
- 右側に埋めたテストが skip / pending でなく現に緑で走っているかも確認する。台帳上は埋まっていても skip で黙殺されていれば、それは守られていないテストである(
../levels-operational/SKILL.md の skip 黙殺の罠)。
- 既存テストを全件転記したかは、テストファイルから抽出した件数と右側の件数の一致で確かめる(読んで分かった気にならない)。
0 段を閉じた直後のゲート
台帳を閉じたら、テストを1件でも書く前に hymme:test-design-reviewer サブエージェントへ台帳のパスを渡して外側から検査させる(台帳の未完・欠番、理由なしの優先度落とし)。違反を解消してから次工程へ。
やらないこと
- 0段を飛ばしてテストを書かない。思いつきで書くと正常系に偏り、境界と異常系が抜ける。
- 台帳を実装後に後付けで埋めない。後から辻褄を合わせると、書いたテストに台帳を寄せるだけになり抜けが見えなくなる。
- 異常系や境界を安易に「優先度低/対象外」へ流して実質スキップしない。落とすなら台帳に理由を1行残す。
- 「巨大だから別タスク」と振る舞いのスコープを自分で縮めない。依存先の仕様も調べて台帳に積む。大きい対象は MECE 分割して順に消化し、分割をスコープ除外と混同しない。
- 台帳は
tasks/test-design/ 配下・git 管理外。T-xxx を本体へ漏らさない(../_shared/stealth-artifacts.md)。
次の工程
台帳が閉じたら(全 T-ID [x]・欠番なし・証跡提示済み)、test-catalog スキルで各 T-ID に手法を割り当てる。
