tdd-workflow

テスト駆動開発（TDD）ワークフロー

ユーザーが明示的にテストを求めた場合にのみ、このスキルを使用してください。それ以外の場合は、差分と変更が加わるコードを確認して検証してください。

テストを設計と実装の指針とする、規律ある開発アプローチです。

TDD のマントラ

「失敗するテストなしに、コードを1行も書いてはいけません。」

RED-GREEN-REFACTOR サイクル

RED フェーズ：失敗するテストを書く

目標：実装の前に、期待される動作を定義します。

ルール：

1. 失敗する最小のテストを書く
2. テストは正しい理由で失敗しなければならない
3. テストで意図を明確に表現する
4. まだ実装を書かない

例：

// RED: Test the behavior we want
describe("Calculator", () => {
  it("should add two numbers", () => {
    const calc = new Calculator();
    expect(calc.add(2, 3)).toBe(5);
  });
});

// Run: npm test
// Result: FAIL - Calculator is not defined
// This is RED ✓

チェックリスト：

• テストが書かれている
• 実行するとテストが失敗する
• 失敗メッセージが明確である
• テスト名で期待される動作が説明されている

---

GREEN フェーズ：テストを通す

目標：テストを通すための最小限のコードを書きます。

ルール：

1. 動作する最もシンプルな方法を選ぶ
2. 余分な機能を追加しない
3. 最適化しない
4. テストを通すことだけに集中する

例：

// GREEN: Minimum implementation to pass
class Calculator {
  add(a: number, b: number): number {
    return a + b; // Simplest thing that works
  }
}

// Run: npm test
// Result: PASS
// This is GREEN ✓

チェックリスト：

• テストが成功する
• 余分なコードを追加していない
• 実装が最小限である

---

REFACTOR フェーズ：コードを改善する

目標：テストが成功する状態を保ちながら、コードを整理します。

ルール：

1. テストが成功している場合にのみリファクタリングする
2. 変更のたびにテストを実行する
3. 動作ではなく設計を改善する
4. 小さく段階的に変更する

リファクタリングの例：

• メソッドを抽出する
• 分かりやすい名前に変更する
• 重複を削除する
• パフォーマンスを改善する
• 型やドキュメントを追加する

チェックリスト：

• テストが引き続き成功する
• コードがより読みやすくなっている
• 動作に変更がない
• 次の RED に進む準備ができている

---

実践での TDD

新機能の開始

1. Write high-level acceptance test (may not run yet)
2. Write first unit test (RED)
3. Implement minimum code (GREEN)
4. Refactor if needed (REFACTOR)
5. Repeat 2-4 until feature complete
6. Verify acceptance test passes

テストの構成（AAA パターン）

it("should [behavior] when [condition]", () => {
  // Arrange - Set up test data and dependencies
  const user = createTestUser({ role: "admin" });
  const service = new UserService();

  // Act - Execute the code under test
  const result = service.getPermissions(user);

  // Assert - Verify expected outcomes
  expect(result).toContain("delete");
  expect(result).toContain("edit");
});

テストの命名規則

[Unit]_[Scenario]_[ExpectedResult]

例：

• add_withPositiveNumbers_returnsSum
• login_withInvalidPassword_throwsAuthError
• getUser_whenNotFound_returnsNull

---

テストのカテゴリ

単体テスト

• 単一の関数／クラスを分離してテストする
• すべての依存関係をモックする
• 高速（テストあたり <10ms）
• 開発中は常に実行する

統合テスト

• 複数のコンポーネントを組み合わせてテストする
• 実際のデータベースを使用する（テスト用インスタンス）
• 低速だが、より現実に近い
• コミット前に実行する

エンドツーエンドテスト

• UI を通してシステム全体をテストする
• 最も低速だが、最も現実に近い
• CI/CD パイプラインで実行する
• 重要なユーザーパスを網羅する

---

TDD のベストプラクティス

DO：

• 最もシンプルなケースから始める
• 一度に1つのテストを書く
• テストを独立させる
• 実装ではなく動作をテストする
• 説明的なテスト名を使う
• テストが成功するたびにコミットする

DON'T：

• テストより先にコードを書く
• プライベートメソッドを直接テストする
• フレームワークのコードをテストする
• 実装に過度に適合したテストを書く
• リファクタリングのフェーズを省略する

---

テストするエッジケース

必ずテストしてください：

• 空の入力（null、undefined、[]、{}、''）
• 境界値（0、-1、MAX_INT、最小／最大の日付）
• エラー条件（ネットワーク障害、無効な入力）
• 権限の境界
• 同時アクセス
• Unicode／特殊文字

---

テストカバレッジのガイドライン

指標	最低値	目標
ステートメント	70%	85%
分岐	70%	80%
関数	80%	90%
行	70%	85%

カバレッジは指標であり、目標ではありません。カバレッジが100%でも、バグがないとは限りません。

---

クイックリファレンス

RED    → Write failing test (define behavior)
GREEN  → Minimum code to pass (make it work)
REFACTOR → Clean up (make it right)
COMMIT → Save progress (make it permanent)

---

よくある TDD の間違い

間違い	問題	解決策
実装をテストする	テストが壊れやすい	動作／結果をテストする
テストが大きすぎる	デバッグが難しい	小さく、焦点を絞ったテストにする
状態を共有する	テストが不安定になる	各テストを分離する
テストが遅い	テストが省略される	外部依存関係をモックする
明白なコードをテストする	時間を浪費する	ロジックに集中する