qe-tdd-london-chicago

テスト駆動開発：ロンドン学派とシカゴ学派

<default_to_action> TDD を実施するとき、またはテストスタイルを選ぶとき：

1. コードの種類を特定します：ドメインロジック → シカゴ学派、外部依存関係 → ロンドン学派
2. 最初に失敗するテストを書きます（Red フェーズ）
3. テストを通すための最小限のコードを実装します（Green フェーズ）
4. テストを通したままリファクタリングします（Refactor フェーズ）
5. 次の機能についてサイクルを繰り返します

スタイル選択のクイックガイド：

• 純粋関数／計算 → シカゴ学派（実オブジェクト、状態の検証）
• 依存関係を持つコントローラー／サービス → ロンドン学派（モック、インタラクションの検証）
• 値オブジェクト → シカゴ学派（最終状態をテスト）
• API 統合 → ロンドン学派（外部サービスをモック）
• 実践では両方を組み合わせます（コントローラーにはロンドン学派、ドメインにはシカゴ学派）

成功の重要要因：

• テストは設計を導くものであり、単に検証するだけではありません
• テスト対象があることを確かめるため、最初にテストを失敗させます
• 最小限のコードを書きます。テスト対象を超える機能は追加しません </default_to_action>

クイックリファレンスカード

使用する場面

• テストファーストのアプローチで新機能を始めるとき
• テストカバレッジのあるレガシーコードをリファクタリングするとき
• チームに TDD の実践方法を教えるとき
• モックと実オブジェクトのどちらを使うか選ぶとき

TDD サイクル

フェーズ	アクション	規律
Red	失敗するテストを書く	失敗することを確認し、メッセージが明確か確認します
Green	テストを通す最小限のコードを書く	余分な機能は追加せず、リファクタリングもしません
Refactor	構造を改善する	テストを通したままにし、新しい機能は追加しません

学派の比較

観点	シカゴ学派（古典派）	ロンドン学派（モック派）
コラボレーター	実オブジェクト	モック／スタブ
検証	状態（結果をアサート）	インタラクション（呼び出しをアサート）
分離	低い（統合される）	高い（単体のみ）
リファクタリング	容易	難しい（モックが壊れる）
設計へのフィードバック	使用を通じて現れる	最初から明示される

エージェントの連携

• qe-test-generator：両学派のテストを生成します
• qe-test-implementer：最小限のコードを実装します（Green）
• qe-test-refactorer：安全にリファクタリングします（Refactor）

---

シカゴ学派（状態ベース）

理念： 公開 API を通じて観測可能な振る舞いをテストします。テストを利用者の使い方に近づけます。

// State verification - test final outcome
describe('Order', () => {
  it('calculates total with tax', () => {
    const order = new Order();
    order.addItem(new Product('Widget', 10.00), 2);
    order.addItem(new Product('Gadget', 15.00), 1);

    expect(order.totalWithTax(0.10)).toBe(38.50);
  });
});

シカゴ学派が適している場面：

• 状態が明確なドメインロジック
• アルゴリズムと計算
• 値オブジェクト（Money、Email）
• 単純なコラボレーション
• 新しいドメインの学習

---

ロンドン学派（モックベース）

理念： 各ユニットを分離してテストします。オブジェクト同士のコラボレーション方法に注目します。

// Interaction verification - test method calls
describe('Order', () => {
  it('delegates tax calculation', () => {
    const taxCalculator = {
      calculateTax: jest.fn().mockReturnValue(3.50)
    };
    const order = new Order(taxCalculator);
    order.addItem({ price: 10 }, 2);

    order.totalWithTax();

    expect(taxCalculator.calculateTax).toHaveBeenCalledWith(20.00);
  });
});

ロンドン学派が適している場面：

• 外部との統合（DB、API）
• 副作用を伴うコマンドパターン
• 複雑なワークフロー
• 時間のかかる処理（ネットワーク、I/O）

---

混合アプローチ（推奨）

// London for controller (external deps)
describe('OrderController', () => {
  it('creates order and sends confirmation', async () => {
    const orderService = { create: jest.fn().mockResolvedValue({ id: 123 }) };
    const emailService = { send: jest.fn() };

    const controller = new OrderController(orderService, emailService);
    await controller.placeOrder(orderData);

    expect(orderService.create).toHaveBeenCalledWith(orderData);
    expect(emailService.send).toHaveBeenCalled();
  });
});

// Chicago for domain logic
describe('OrderService', () => {
  it('applies discount when threshold met', () => {
    const service = new OrderService();
    const order = service.create({ items: [...], total: 150 });

    expect(order.discount).toBe(15); // 10% off > $100
  });
});

---

よくある落とし穴

❌ モックの使いすぎ（ロンドン学派）

// BAD - mocking everything
const product = { getName: jest.fn(), getPrice: jest.fn() };

改善策： 外部依存関係だけをモックします。

❌ 内部のモック化

// BAD - testing private methods
expect(order._calculateSubtotal).toHaveBeenCalled();

改善策： 公開された振る舞いだけをテストします。

❌ テストのつらさは設計のつらさ

• 多くのモックが必要ですか？ → 依存関係が多すぎます
• セットアップが難しいですか？ → コンストラクターが多くの処理を担いすぎています
• データベースなしではテストできませんか？ → 密結合の問題です

---

エージェント支援による TDD

// Agent generates tests in both schools
await Task("Generate Tests", {
  style: 'chicago',      // or 'london'
  target: 'src/domain/Order.ts',
  focus: 'state-verification'  // or 'collaboration-patterns'
}, "qe-test-generator");

// Agent-human ping-pong TDD
// Human writes test concept
const testIdea = "Order applies 10% discount when total > $100";

// Agent generates formal failing test (Red)
await Task("Create Failing Test", testIdea, "qe-test-generator");

// Human writes minimal code (Green)

// Agent suggests refactorings
await Task("Suggest Refactorings", { preserveTests: true }, "qe-test-refactorer");

---

エージェント連携のヒント

メモリの名前空間

aqe/tdd/
├── test-plan/*        - TDD session plans
├── red-phase/*        - Failing tests generated
├── green-phase/*      - Implementation code
└── refactor-phase/*   - Refactoring suggestions

フリートの連携

const tddFleet = await FleetManager.coordinate({
  workflow: 'red-green-refactor',
  agents: {
    testGenerator: 'qe-test-generator',
    testExecutor: 'qe-test-executor',
    qualityAnalyzer: 'qe-quality-analyzer'
  },
  mode: 'sequential'
});

---

関連スキル

• エージェント型品質エンジニアリング - エージェント連携による TDD
• リファクタリングパターン - Refactor フェーズの手法
• API テストパターン - API テストにおけるロンドン学派

---

覚えておくこと

シカゴ学派： 状態をテストし、実オブジェクトを使い、自由にリファクタリングします ロンドン学派： インタラクションをテストし、依存関係をモックし、まずインターフェースを設計します 両方： まずテストを書き、テストを通し、リファクタリングします

どちらが「正しい」ということはありません。状況に応じて選び、必要に応じて組み合わせてください。目標は、適切に設計され、テストされたコードです。

エージェントを使う場合： エージェントはテストの生成、Green フェーズの検証、リファクタリング案の提案に優れています。人間が設計上の判断に集中できるよう、エージェントを使って TDD の規律を保ちましょう。