# コーディングとテストガイド ## 概要 このガイドは、開発ガイドのコーディングとテスト部分を詳細化したドキュメントです。TDD（テスト駆動開発）を中核とした実装プロセスの具体的な手順と、品質を維持するための規律を定義します。 ## 基本原則 ### TDD（Test-Driven Development）の三つの原則 1. **失敗するテストを書くまで、プロダクションコードを書いてはならない** 2. **失敗するテストは、失敗するのに十分なだけ書く** 3. **現在失敗しているテストを成功させる以上のプロダクションコードを書いてはならない** ### Red-Green-Refactor サイクル ```plantuml @startuml skinparam state { BackgroundColor Red BackgroundColor LightGreen BackgroundColor LightBlue } [*] --> Red state Red { [*] --> テストを書く テストを書く : 失敗する } Red --> Green : 最小限の実装 state Green { [*] --> テストが通る テストが通る : 最小限のコード } Green --> Refactor : テスト成功 state Refactor { [*] --> リファクタリング リファクタリング : 設計改善 } Refactor --> Red : 次のテスト Refactor --> [*] : 完了 note right of Red 失敗するテストを 最初に書く end note note right of Green テストを通す 最小限のコードを書く end note note right of Refactor 重複を除去し 設計を改善する end note @enduml ``` ## イテレーション開発フロー ### 全体プロセス ```plantuml @startuml "イテレーション開発プロセス" start partition "イテレーション開始" { } repeat :TODO確認; partition "TDD実装サイクル" { repeat :TODO選択; repeat :失敗テスト作成 (Red); :最小実装 (Green); :リファクタリング (Refactor); :品質チェック; if (品質OK?) then (yes) :コミット; else (no) :修正; endif repeat while (TODO完了?) partition "コードレビュー" { } repeat while (全TODO完了?) } if (イテレーション完了?) then (yes) partition "受け入れ" { partition "ユーザーレビュー" { } if (受け入れOK?) then (yes) partition "ふりかえり" { } else (no) partition "修正対応" { } endif } else (no) partition "設計リファクタリング" { partition "アーキテクチャリファクタリング" { } partition "データモデルリファクタリング" { } partition "ドメインモデルリファクタリング" { } partition "UIリファクタリング" { } } endif repeat while (次のTODO?) stop @enduml ``` ## アプローチ戦略 ### インサイドアウト vs アウトサイドイン ```plantuml @startuml title 実装アプローチ選択フロー start :ユーザーストーリー分析; if (基本CRUD実装済み?) then (はい) if (ドメインロジックが複雑?) then (はい) :ドメインモデル中心; #lightgreen:アウトサイドイン推奨; note right UIからスタート ドメインロジックを 段階的に実装 end note else (いいえ) :シンプルな機能追加; #lightblue:どちらでも可; endif else (いいえ) :貧血ドメインモデル; #yellow:インサイドアウト推奨; note right データ層から開始 基盤を固めて 上位層へ展開 end note endif if (API実装済み?) then (はい) #lightblue:インサイドアウト活用; note right 既存APIを利用し 内部実装を改善 end note else (いいえ) #lightgreen:アウトサイドイン活用; note right UIのニーズから API設計を導出 end note endif :アプローチ決定; stop @enduml ``` ### インサイドアウトアプローチ ```plantuml @startuml title インサイドアウトアプローチ participant "テスト" as test participant "データベース層" as db participant "インフラ層" as infra participant "ドメイン層" as domain participant "サービス層" as service participant "プレゼンテーション層" as ui == Phase 1: データベース == test -> db: テーブル定義テスト activate db db --> test: スキーマ検証 deactivate db == Phase 2: インフラストラクチャ == test -> infra: リポジトリテスト activate infra infra -> db: CRUD操作 db --> infra: 結果 infra --> test: 永続化確認 deactivate infra == Phase 3: ドメイン == test -> domain: ビジネスロジックテスト activate domain domain -> infra: データ取得 infra --> domain: エンティティ domain --> test: ビジネスルール検証 deactivate domain == Phase 4: サービス == test -> service: ユースケーステスト activate service service -> domain: ドメイン操作 domain --> service: 結果 service --> test: トランザクション確認 deactivate service == Phase 5: プレゼンテーション == test -> ui: UIテスト activate ui ui -> service: API呼び出し service --> ui: レスポンス ui --> test: 画面表示確認 deactivate ui @enduml ``` ### アウトサイドインアプローチ ```plantuml @startuml title アウトサイドインアプローチ participant "受け入れテスト" as at participant "プレゼンテーション層" as ui participant "サービス層" as service participant "ドメイン層" as domain participant "インフラ層" as infra participant "データベース層" as db == Phase 1: 受け入れテスト == at -> ui: ユーザーシナリオ activate at ui --> at: モック応答 deactivate at == Phase 2: UI実装 == at -> ui: UIテスト activate ui ui -> service: サービス呼び出し（モック） service --> ui: モックレスポンス ui --> at: 画面動作確認 deactivate ui == Phase 3: サービス実装 == at -> service: 統合テスト activate service service -> domain: ドメイン呼び出し（モック） domain --> service: モック結果 service --> at: ビジネスロジック確認 deactivate service == Phase 4: ドメイン実装 == at -> domain: ドメインテスト activate domain domain -> infra: リポジトリ呼び出し（モック） infra --> domain: モックデータ domain --> at: ビジネスルール確認 deactivate domain == Phase 5: インフラ実装 == at -> infra: 永続化テスト activate infra infra -> db: DB操作 db --> infra: 実データ infra --> at: データ永続化確認 deactivate infra @enduml ``` ## TDD実装の詳細手順 ### 1. TODO作成 ```markdown ## TODOリストの例 - [ ] ユーザー登録機能 - [ ] Userエンティティの作成 - [ ] 必須フィールドの検証 - [ ] メールアドレスの形式検証 - [ ] パスワードの強度チェック - [ ] UserRepositoryの実装 - [ ] save()メソッド - [ ] findByEmail()メソッド - [ ] existsByEmail()メソッド - [ ] UserServiceの実装 - [ ] register()メソッド - [ ] 重複チェック - [ ] パスワードハッシュ化 - [ ] UserControllerの実装 - [ ] POST /users エンドポイント - [ ] バリデーション - [ ] エラーハンドリング ``` ### 2. Red フェーズ（失敗するテストを書く） ```java // UserTest.java @Test void ユーザー作成時に必須フィールドが検証される() { // Given String email = "test@example.com"; String password = "SecurePass123!"; String name = "山田太郎"; // When User user = new User(email, password, name); // Then assertThat(user.getEmail()).isEqualTo(email); assertThat(user.getName()).isEqualTo(name); // パスワードはハッシュ化されている assertThat(user.getPassword()).isNotEqualTo(password); } @Test void 無効なメールアドレスで例外が発生する() { // Given String invalidEmail = "invalid-email"; // When/Then assertThrows(IllegalArgumentException.class, () -> { new User(invalidEmail, "password", "name"); }); } ``` ### 3. Green フェーズ（最小限の実装） ```java // User.java public class User { private String email; private String password; private String name; public User(String email, String password, String name) { if (!isValidEmail(email)) { throw new IllegalArgumentException("無効なメールアドレス"); } this.email = email; this.password = hashPassword(password); this.name = name; } private boolean isValidEmail(String email) { return email != null && email.contains("@"); } private String hashPassword(String password) { // 簡単なハッシュ化の実装（後で改善） return "hashed_" + password; } // getters... } ``` ### 4. Refactor フェーズ（設計改善） ```java // User.java (リファクタリング後) public class User { private final Email email; private final Password password; private final Name name; public User(String email, String password, String name) { this.email = new Email(email); this.password = new Password(password); this.name = new Name(name); } // getters... } // Email.java (値オブジェクト) public class Email { private static final Pattern VALID_EMAIL_PATTERN = Pattern.compile("^[A-Za-z0-9+_.-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$"); private final String value; public Email(String value) { if (value == null || !VALID_EMAIL_PATTERN.matcher(value).matches()) { throw new IllegalArgumentException("無効なメールアドレス: " + value); } this.value = value; } public String getValue() { return value; } } // Password.java (値オブジェクト) public class Password { private static final int MIN_LENGTH = 8; private final String hashedValue; public Password(String rawPassword) { validate(rawPassword); this.hashedValue = BCrypt.hashpw(rawPassword, BCrypt.gensalt()); } private void validate(String password) { if (password == null || password.length() < MIN_LENGTH) { throw new IllegalArgumentException( "パスワードは" + MIN_LENGTH + "文字以上必要です" ); } } public boolean matches(String rawPassword) { return BCrypt.checkpw(rawPassword, hashedValue); } } ``` ## 品質チェックリスト ### コミット前の必須確認事項 ```bash # 1. テスト実行 ./gradlew test # または npm test # 2. コードフォーマット ./gradlew spotlessApply # または npm run format # 3. 静的解析 ./gradlew check # または npm run lint # 4. ビルド確認 ./gradlew build # または npm run build # 5. カバレッジ確認 ./gradlew jacocoTestReport # または npm run test:coverage ``` ### 品質基準 | 項目 | 基準 | 必須/推奨 | |------|------|-----------| | テストカバレッジ | 80%以上 | 必須 | | 循環的複雑度 | 10以下 | 必須 | | メソッドの行数 | 20行以下 | 推奨 | | クラスの行数 | 200行以下 | 推奨 | | 重複コード | 0% | 必須 | | コンパイラ警告 | 0個 | 必須 | | Linter警告 | 0個 | 必須 | ## コミット規約 ### コミットメッセージフォーマット ``` ():