By name: developing-backend description: バックエンド開発の TDD ワークフロー。Red-Green-Refactor サイクル、インサイドアウトアプローチ、品質チェックリスト。Java/Spring Boot のバックエンド実装時に使用。
バックエンド開発ガイド
TDD サイクルに従ったバックエンド開発を支援します。
Instructions
1. 参照ドキュメント
- @docs/reference/コーディングとテストガイド.md - ワークフロー
- @docs/design/architecture_backend.md - バックエンドアーキテクチャ
- @docs/design/data-model.md - データモデル
- @docs/design/domain-model.md - ドメインモデル
- @docs/design/tech_stack.md - 技術スタック
- @docs/design/test_strategy.md - テスト戦略
2. TDD サイクルの実践
Red-Green-Refactor サイクルを厳密に実行：
- Red フェーズ: 失敗するテストを最初に書く
- Green フェーズ: テストを通す最小限のコードを実装
- Refactor フェーズ: 重複を除去し設計を改善
3. アプローチ戦略の選択
- インサイドアウト: データ層から開始し上位層へ展開（推奨）
- アウトサイドイン: API から開始しドメインロジックを段階的に実装
4. テストコマンド
# 全テスト実行
cd apps/backend && ./gradlew test
# 特定テストクラス実行
cd apps/backend && ./gradlew test --tests "UserServiceTest"
# テストカバレッジ確認
cd apps/backend && ./gradlew jacocoTestReport
5. API ドキュメント
バックエンドには Swagger UI が組み込まれています。
# バックエンドを起動
cd apps/backend && ./gradlew bootRun
# Swagger UI: http://localhost:8080/swagger-ui.html
# OpenAPI JSON: http://localhost:8080/v3/api-docs
# OpenAPI YAML: http://localhost:8080/api-docs.yaml
6. 品質チェックリスト
- すべてのテストがパス
- ESLint/コンパイラの警告がゼロ
- テストカバレッジが目標を満たしている
- 単一の論理的作業単位を表現
- コミットメッセージが変更内容を明確に説明
7. コンテキスト管理
長時間の開発セッションでは Context limit reached エラーを回避するため、タスクの区切りごとに /compact を実施してコンテキストを圧縮する。
/compact を実施するタイミング:
- TDD サイクル（Red-Green-Refactor）を数回繰り返した後
- ユーザーストーリー 1 件の実装が完了したとき
- コミット完了後、次のタスクに着手する前
- テストスイートの実行と結果確認が完了したとき
運用ルール:
/compact実施前に、現在の作業状態と次のタスクをメモとして出力する/compact実施後、次のタスクの作業を継続する- 大規模なユーザーストーリーでは、サブタスクごとに
/compactを検討する
8. 注意事項
- 前提条件: Java/Gradle のテスト環境が設定済みであること
- 制限事項: TDD の三原則を厳密に守る（テストなしでプロダクションコードを書かない）
- 推奨事項: コミット前に必ず品質チェックリストを実行
- 作業完了後に対象のイテレーション @docs/development/iteration_plan-N.md の進捗を更新する
Examples
新機能の TDD 実装
- 失敗するテストを書く（Red）
- テストを通す最小限のコードを実装（Green）
- 重複を排除し設計を改善（Refactor）
- 品質チェックリストを実行してコミット
ベストプラクティス
- TODO 駆動開発: タスクを細かい TODO に分割してから実装開始
- 小さなサイクル: Red-Green-Refactor を 10-15 分で完了させる
- 継続的コミット: 各サイクル完了時に動作する状態でコミット
- Rule of Three: 同じコードが 3 回現れたらリファクタリング