TDDワークフロースキル

TDDサイクル

1. Red フェーズ（テストを先に書く）

手順

1. •テストファイルを作成する（*.spec.ts）
2. •テスト対象の期待する振る舞いをテストケースとして記述する
3. •テストを実行し、失敗することを確認する

テストの書き方

describe('[テスト対象クラス名]', () => {
  beforeEach(async () => {
    // テスト用のモック・フィクスチャを準備
  });

  it('[期待する振る舞いを日本語で記述]', async () => {
    // Arrange: テストデータの準備
    // Act: テスト対象の実行
    // Assert: 結果の検証
  });
});

DDD層別のテスト方針

2. Green フェーズ（最小限の実装）

手順

1. •テストが通る最小限のコードを実装する
2. •「動くコード」を最優先する
3. •テストを実行し、すべて通ることを確認する

原則

• •完璧なコードを書こうとしない
• •テストに書かれていない機能は実装しない
• •既存のテストが壊れていないことも確認する

3. Refactor フェーズ（品質改善）

手順

1. •コードの重複を排除する
2. •命名を改善する（DDD規約に準拠）
3. •不変性、ファクトリメソッド等のDDD規約への適合を確認する
4. •テストを再実行し、すべて通ることを確認する

リファクタリング観点

• •単一責任の原則に違反していないか
• •DDD層の責務が正しく分離されているか
• •命名がドメインの言葉を使っているか
• •不要なコメントや死んだコードがないか
  • •コメントは基本的には記述せず、コード自体で意味を説明できるようにする

テスト実行コマンド

重要: テストは必ずDockerコンテナ内で実行する。

# 特定のテスト実行
docker compose exec backend npm run test -- /src/path/to/test.spec.ts

# 全テスト実行
docker compose exec backend npm run test

テスト失敗時の対応

1. •エラーメッセージを正確に読む
2. •期待値と実際の値の差分を確認する
3. •Greenフェーズの実装を修正する（テストは変更しない）
4. •テストを再実行する
5. •3回修正しても通らない場合は、テストの前提条件を見直す

テストのアンチパターン

• •テストが実装の詳細に依存している（privateメソッドのテスト等）
• •テスト間に順序依存がある
• •テストデータが共有されている（各テストは独立すべき）
• •テストデータがテストの並列実行時に重複エラーになってしまう
• •モックが多すぎる（設計の問題のサイン）
• •テスト名が意味のない名前になっている
• •テスト名が過剰な説明文を反映したものになっている