Metanaka Nuxt TDD

Overview

Kent Beck の Canon TDD を Nuxt の unit-testable production behavior に適用する。 この skill は重要度を分類しない。Scope の適用判定、Workflow の番号順、Reporting の報告項目を必須とする。

Scope

対象は path だけでなく observable production behavior の変更かで判断する。

• composable、model、utility、adapter、validation、状態遷移
• Vue component から抽出する domain/application behavior
• feature/shared の公開 contract

対象外:

• Vue template、CSS、表示 wiring だけの変更
• Playwright E2E のみで扱う browser flow
• behavior-preserving production refactor、test-only cleanup、coverage addition
• generated artifact、documentation、tool/configuration だけの変更

対象外でも TypeScript/Vue/test code に触れたら関連 test と pnpm tc で既存動作を確認する。behavior-preserving refactor を TDD 対象変更より先に行う場合は、関連 test の green を checkpoint にしてから RED を開始する。

Companion Skills

• metanaka-nuxt-coding: TypeScript/Vue script のコード表現。
• metanaka-nuxt-testing: 完成する Vitest code の構造と検証内容。
• metanaka-nuxt-architecture: 配置、責務、公開 contract、i18n、Firestore 境界を設計・変更・レビューする場合。既存 contract 内の純粋な分岐だけなら不要。
• dads-design-system: DADS component/UI guidance が必要な Vue UI 変更の場合。この TDD の対象外部分へ適用する。

Workflow

1. テストリストを作る。

   • 期待する observable behavior を箇条書きにする。
   • 実装方針、内部構造、抽象化案を混ぜない。
   • 要求 behavior と必要な回帰観点を対象にし、別 behavior は follow-up と区別する。
   • 仕様語が曖昧なら具体例を確認し、確認できなければ既存仕様に合う最小仮定を明記する。

2. 次の behavior をひとつ選ぶ。

   • 最小の observable behavior から始める。
   • 同じ behavior を直接検証する既存 test を production symbol と behavior 名で検索する。
   • 既存 failing test が要求 bug を直接再現するなら重複 test を追加しない。
   • 入力だけが異なる同値分割・境界値は1つの parameterized test として扱ってよい。結果や状態遷移が異なる case は別 cycle にする。

3. failing Vitest を1つ用意する。

   • 新規 test は対象 file と同じ slice に置き、metanaka-nuxt-testing に従う。
   • 公開 API の呼び方を test で設計してよいが、内部実装設計は green 後まで遅らせる。

4. RED を確認する。

   • Nuxt project root で対象 file、可能なら対象 case だけを実行する。

pnpm test -- <path/to/test.test.ts> -t "<test title>"

• package.json の script が引数を受ける形式を正とする。
• 失敗理由が要求 behavior を示すことを確認し、🔴 RED: <失敗理由> を記録する。
• pass したら未実装 behavior を選び直す。要求内に残っていなければ既存実装で充足と報告する。
• import typo、syntax、既存 API の読み違いは test 側を直し、期待する失敗まで進める。
• 未実装 public API の type/compile error は、behavior を直接表す場合だけ意図した RED として扱う。

5. 最小実装で GREEN にする。

   • 現在の failing test と既存 test を通す最小変更だけを行う。
   • assertion 削除、期待値の実行結果からのコピー、無関係な production behavior の追加で green にしない。
   • 新しい観点は実装へ混ぜずテストリストへ追加する。

6. GREEN を確認する。

   • 同じ対象 test を実行し、通ったら 🟢 GREEN: <確認内容> を記録する。
   • 関連 test は影響範囲に応じて実行する。cycle ごとの全 suite 実行は避ける。

7. 必要なら refactor する。

   • green 後だけ行う。名前、重複、pure/impure 境界、責務を整える。
   • 同じ test を再実行し、🟣 REFACTOR: <整理内容> を記録する。
   • 重複は抽象化の命令ではなく hint とする。

8. テストリストが空になるまで繰り返す。

   • 1 cycle につき1 behavior を保つ。
   • 最後に関連 unit test suite と pnpm tc を実行する。
   • i18n source を変更した場合は pnpm run i18n:merge も実行する。

Reporting

• 選んだテストリスト項目。
• 🔴 RED で確認した失敗理由。
• GREEN のための最小実装。
• 🟢 GREEN で通した確認内容。
• refactor した場合の 🟣 REFACTOR。
• 最終 verification command と結果。