tdd

Prompt file imported from kontsuyo/my-app-v2 (.github/prompts/tdd.prompt.md). Copyright stays with the author.

あなたはこれからテスト駆動開発(TDD)でタスクを進める。Kent Beck の "Test-Driven Development: By Example" と、和田卓人(t_wada)が日本で広めたTDDの実践スタイルに従うこと。

適用範囲(厳格サイクルは Phase 3 から)

• Phase 1〜2(基盤・ドメインモデル)は Django の定型コードが中心のため、厳格な Red→Green→Refactor は適用しない。カスタム User モデル・AUTH_USER_MODEL・admin 登録・createsuperuser などは手早く実装し、必要なら email 一意制約のような固有ロジックに絞って最小限のテストを残す。
• 厳格な TDD サイクルは Phase 3(DRF API 実装)から本格適用する。 権限制御(IsOwnerOrReadOnly)、いいねの二重防止、シリアライザの like_count/liked_by_me、署名付きURL のバリデーションなど、自分で書くビジネスロジックを対象にする。

絶対に守るルール

1. テストなしでプロダクションコードを1行も書かない。 必ず先にテストを書く。
2. Red → Green → Refactor のサイクルを1項目ずつ回す。サイクルを飛ばしたり、まとめて複数のテストを書いたりしない。
3. 1歩を可能な限り小さくする。 大きく踏み出せそうに見えても、あえて小さい一歩から始める。
4. 各ステップでテストを実行し、結果(失敗/成功)を確認してから次に進む。確認せずに「たぶん通る」で先に進まない。
5. Green にする実装は最小限。将来のための抽象化や汎用化を先回りして行わない(YAGNI)。必要に応じて「仮実装(fake it)」→「三角測量(triangulation)」→「明白な実装」の順で育てる。
6. Refactor フェーズではテストの期待値を変更しない。重複除去・意図の明確化のみ行い、変更のたびにテストを再実行してグリーンを確認する。
7. テスト名は「何をすると何が起きるか」が読んだだけで分かるようにする。テスト関数名には日本語を混ぜず、英語の snake_case などで簡潔に書く。1テスト1関心事を基本にする。
8. 失敗するテストを書いたら、実装前に一度実行して「意図した理由で失敗している」ことを確認する(タイポやテスト自体のバグで失敗していないかのチェック)。
9. テストだけでは意図が伝わりにくいときは、そのテストの直前に1行コメントで「何を検証するテストか」を補う。長い説明は不要だが、読み手が目的を即座に把握できることを優先する。

進め方

1. TODOリストを作る: タスクを小さく分割し、箇条書きのテストケース一覧を作成してユーザーに提示する。不安なところ・壊れやすいところから着手する。
2. リストの先頭から1件ずつ処理する:
   • Red: その項目に対応する失敗するテストを1つだけ書く。実行して意図した理由で失敗することを確認する。
   • Green: テストを通す最小限のコードを書く。実行してグリーンになることを確認する。
   • Refactor: 重複や意図の不明瞭さがあれば整理する。小さな変更ごとにテストを再実行し、グリーンを維持する。
   • TODOリストを更新(完了マーク・新たに見つかったタスクの追加)し、次の項目に進む。
3. 各 Green/Refactor の節目はコミット単位の目安として意識する。ただし実際の git commit はユーザーの許可なく行わず、タイミングを提案するだけに留める。
4. plan.md の該当チェックリスト項目は、テストと実装が揃った時点でチェックを付ける。

このプロジェクトでのテスト実行

• Phase 3 の開始前に pytest と pytest-django を開発依存として追加し、以降のバックエンドテストでは pytest を使う。

  uv add --dev pytest pytest-django

• TDD ループでは --reuse-db を付け、変更中のテストだけを指定して実行する。マイグレーション変更後などテストDBを作り直す必要がある場合は --create-db を使う。

  uv run pytest --reuse-db accounts/tests.py::UserModelTests::test_duplicate_email_raises_integrity_error

• 各機能の完了時や共有コード変更後は、バックエンドの全テストを実行する。

  uv run pytest --reuse-db

• factory_boy は Phase 4 で必要になった時点で追加する。pytest-xdist の並列実行は初期化コストがあるため、テスト数が増えてから必要に応じて導入する。
• バックエンドは backend/ 配下、Django アプリ単位でテストを配置する(accounts/tests.py または accounts/tests/ ディレクトリ)。

開始時の確認

実装対象が曖昧な場合は、着手前に対象(モデル/API/関数など)と期待する振る舞いを簡潔に確認してから、TODOリストの提示に進む。