Test-Driven Development (TDD) ガイド

概要

Test-Driven Development (TDD) は、本番コードを書く前にテストを書く開発手法です。この手法は、より保守性の高い、信頼性のあるソフトウェアの構築に役立ちます。

TDD サイクル

TDD は「Red-Green-Refactor」という 3 つのステップから構成されています:

1. Red (赤) - テストの失敗

まず、機能の要件を定義するテストを書きます。このテストは、実装がまだ存在しないため、失敗します。

describe('Calculator', () => {
  it('should add two numbers correctly', () => {
    const calculator = new Calculator();
    expect(calculator.add(2, 3)).toBe(5);
  });
});

2. Green (緑) - テストを通す

次に、テストを通すための最小限の実装を行います。このステップの目標は、機能を正しく実装することではなく、テストを通すことです。

class Calculator {
  add(a, b) {
    return a + b;
  }
}

3. Refactor (リファクタリング) - コードの改善

テストが通った後、コードの品質を改善します。この段階でも、すべてのテストが通ったままであることを確認します。

class Calculator {
  add(a, b) {
    if (typeof a !== 'number' || typeof b !== 'number') {
      throw new Error('Both arguments must be numbers');
    }
    return a + b;
  }
}

TDD のメリット

1. 設計の向上

テストを先に書くことで、関数やクラスのインターフェイスを慎重に設計することになります。これにより、より直感的で使いやすい API が生まれます。

2. バグの削減

テストを包括的に書くことで、多くのバグを開発段階で発見・修正できます。

3. リファクタリングの安心感

包括的なテストがあれば、コードを大胆にリファクタリングでき、回帰を恐れる必要がありません。

4. ドキュメント化

テストは実装がどのように動作すべきかを示す、実行可能なドキュメントとして機能します。

5. 開発速度の向上

長期的には、TDD により開発サイクルが加速します。バグ修正に費やされる時間が減少し、新しい機能の開発に集中できるためです。

TDD のベストプラクティス

単一責任の原則

各テストは 1 つの動作のみをテストすべきです。

// 良い例
it('should return true for valid email', () => {
  expect(isValidEmail('test@example.com')).toBe(true);
});

it('should return false for invalid email', () => {
  expect(isValidEmail('invalid-email')).toBe(false);
});

// 悪い例
it('should validate email', () => {
  expect(isValidEmail('test@example.com')).toBe(true);
  expect(isValidEmail('invalid-email')).toBe(false);
});

AAA パターン (Arrange-Act-Assert)

各テストは 3 つの部分から構成されるべきです:

it('should calculate total price with tax', () => {
  // Arrange: テストデータのセットアップ
  const item = { price: 100 };
  const taxRate = 0.1;

  // Act: テスト対象の関数を実行
  const totalPrice = calculateTotalWithTax(item.price, taxRate);

  // Assert: 結果を検証
  expect(totalPrice).toBe(110);
});

意味のあるテスト名

テスト名は、何をテストしているのかを明確に説明すべきです。

// 良い例
it('should throw an error when password is less than 8 characters', () => {
  expect(() => validatePassword('short')).toThrow();
});

// 悪い例
it('should work', () => {
  expect(() => validatePassword('short')).toThrow();
});

テスト環境の隔離

テスト間の依存関係を避けるため、各テストは独立した環境で実行されるべきです。

describe('UserService', () => {
  let userService;

  beforeEach(() => {
    // 各テストの前に新しいインスタンスを作成
    userService = new UserService();
  });

  afterEach(() => {
    // テストの後でクリーンアップ
    userService.cleanup();
  });

  it('should create a user', () => {
    const user = userService.createUser('John');
    expect(user.name).toBe('John');
  });
});

TDD の落とし穴と対策

過度なテスト

すべてのコードをテストする必要はありません。ビジネスロジックとエッジケースに焦点を当ててください。

テストの複雑さ

テストコードを保守性の高い、読みやすいコードに保つことが重要です。テストコードもリファクタリングすべきです。

テストの速度

テストスイートが遅い場合、開発フローが阻害されます。単体テストは高速であるべきです。遅いテスト(統合テストやエンドツーエンドテスト)は別に実行してください。

よくある質問

Q: TDD ではどのくらい詳細にテストを書く必要がありますか?

A: 本番環境で信頼できる動作を保証する程度の詳細さが目安です。エッジケースや既知の問題をカバーすることをお勧めします。

Q: レガシーコードに TDD を適用できますか?

A: はい。レガシーコードには段階的に TDD を導入できます。既存の機能に関連するテストを追加し、新しい機能には TDD を適用してください。

Q: TDD で書く必要のない場合はありますか?

A: はい。UI のプロトタイプやスパイク(実験的な実装)では、TDD が常に最適とは限りません。ただし、本番環境のコードには TDD を推奨します。

参考資料

• Test-Driven Development: By Example - Kent Beck
• Working Effectively with Legacy Code - Michael Feathers
• Jest Documentation
• Mocha Testing Framework