tdd-strict

严格的测试驱动开发

此技能强制执行基于以下核心原则的 TDD 实践：

“如果你没有亲眼看到测试失败，就不知道它是否在测试正确的内容。”

何时启用

• 实现任何新功能时
• 修复 Bug 时（先编写能复现 Bug 的测试，再修复）
• 重构时（修改前后测试都必须通过）
• 扩展 API 时
• 编写任何导出函数时

Red-Green-Refactor 循环

1. RED：编写一个会失败的测试

// ZUERST: Test schreiben
describe('calculateOEE', () => {
  it('should return 0 when availability is 0', () => {
    const result = calculateOEE({ availability: 0, performance: 100, quality: 100 });
    expect(result).toBe(0);
  });
});

// Test MUSS fehlschlagen:
// Error: calculateOEE is not defined
// ODER
// Error: Expected 0 but received undefined

重要：测试必须因正确的原因失败：

• 函数不存在
• 函数返回错误结果
• 不能是：测试本身存在语法错误

2. GREEN：编写能通过测试的最少代码

// DANACH: Minimaler Code
export function calculateOEE(params: OEEParams): number {
  if (params.availability === 0) return 0;
  // Weitere Logik kommt spaeter durch weitere Tests
  return 0;
}

规则：编写能通过测试的最简单代码。

• 不做优化
• 不添加额外功能
• 不做“显而易见”的扩展

3. REFACTOR：清理代码，不引入新行为

// Nach mehreren gruenen Tests: Refactoring erlaubt
export function calculateOEE({ availability, performance, quality }: OEEParams): number {
  return (availability * performance * quality) / 10000;
}

重构规则：

• 所有现有测试都必须继续通过
• 不得添加新行为
• 只改进代码结构
• 每完成一步重构，都要运行测试

13 种无效的自我开脱

这些借口绝不可接受：

1. “太简单，不值得测试”

现实：简单代码需要简单测试。测试只写 1 行也可以。

it('should add two numbers', () => {
  expect(add(2, 3)).toBe(5);
});

2. “我之后再测试”

现实：“之后”意味着“永远不会”。TDD 意味着先写测试。

3. “已经手动测试过了”

现实：手动测试无法复现，也无法扩展。

4. “时间紧，没空写测试”

现实：测试能节省调试时间，并防止回归问题。

5. “私有方法不需要测试”

现实：通过公共 API 测试其行为。如果无法测试，就进行重构。

6. “UI 代码无法测试”

现实：React Testing Library、Playwright 和 Storybook 正是为此而存在。

7. “逻辑很简单”

现实：简单逻辑也会变化。测试能记录预期行为。

8. “我们有 QA 流程”

现实：QA 会在更晚的时候发现 Bug，修复成本也更高。TDD 从一开始就能防止 Bug。

9. “代码只是临时的”

现实：临时代码往往会存在数年。测试也能保护临时代码。

10. “测试会拖慢开发”

现实：从长远来看，TDD 能通过减少调试和回归问题来加快开发。

11. “遗留代码没有测试”

现实：修改前先编写特征测试，再逐步改进。

12. “框架/库已经测试过了”

现实：测试你对框架的使用，而不是测试框架本身。

13. “模拟太麻烦”

现实：如果模拟过于复杂，说明设计过于复杂。进行重构。

验证清单

每次提交前都必须满足：

• 每个导出函数至少有一个测试
• 每个测试在实现前都失败过（已观察到 RED）
• 每个测试只验证一件事（单一断言原则）
• 每个测试只编写最少代码（不过度设计）
• 覆盖边界情况：
  • Null/Undefined 输入
  • 空数组/字符串
  • 边界值（0、MAX_INT、负数）
  • 无效输入（预期出现 TypeError）
• 测试名称描述行为：should [预期结果] when [条件]
• 提交中没有 skip 或 only 测试
• 新代码的覆盖率至少为 80%

实际 TDD 工作流

步骤 1：创建测试文件

# Fuer neue Funktion in src/utils/oee.ts
touch src/utils/oee.test.ts

步骤 2：编写最小的失败测试

// src/utils/oee.test.ts
import { describe, it, expect } from 'vitest';
import { calculateOEE } from './oee';

describe('calculateOEE', () => {
  it('should return 85 for sample manufacturing data', () => {
    const result = calculateOEE({
      availability: 90,
      performance: 95,
      quality: 99
    });
    expect(result).toBeCloseTo(84.645, 2);
  });
});

步骤 3：运行测试（必须失败）

npm run test -- --run src/utils/oee.test.ts

# Erwartete Ausgabe:
# Error: Cannot find module './oee'
# ODER nach Stub:
# Error: Expected 84.645 but received undefined

步骤 4：编写最少的实现代码

// src/utils/oee.ts
export interface OEEParams {
  availability: number;
  performance: number;
  quality: number;
}

export function calculateOEE(params: OEEParams): number {
  return (params.availability * params.performance * params.quality) / 10000;
}

步骤 5：运行测试（必须通过）

npm run test -- --run src/utils/oee.test.ts

# Erwartete Ausgabe:
# PASS src/utils/oee.test.ts

步骤 6：为边界情况编写下一个测试

it('should throw when values exceed 100', () => {
  expect(() => calculateOEE({
    availability: 101,
    performance: 100,
    quality: 100
  })).toThrow('Values must be between 0 and 100');
});

返回步骤 3（RED）-> 步骤 4（GREEN）-> 重复。

识别反模式

禁止：代码后再编写测试

// FALSCH: Code zuerst geschrieben
function add(a: number, b: number): number {
  return a + b;
}

// Dann erst Test geschrieben - UNGUELTIG!
// Du weisst nicht ob der Test das richtige testet

禁止：一次编写过多代码

// FALSCH: Komplette Klasse ohne Tests implementiert
class UserService {
  async create(user: User) { ... }
  async update(id: string, data: Partial<User>) { ... }
  async delete(id: string) { ... }
  async findById(id: string) { ... }
  async findAll(filters: FilterOptions) { ... }
}

// RICHTIG: Eine Methode nach der anderen mit TDD

禁止：为了让测试通过而修改测试

// FALSCH: Test geaendert weil Implementation anders ist
// Vorher: expect(result).toBe(100);
// Nachher: expect(result).toBe(99.5); // "Weil die Formel das so ausgibt"

// RICHTIG: Implementation korrigieren ODER Anforderungen klaeren

特定框架的模式

React 组件（Vitest + Testing Library）

import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';

describe('LoginButton', () => {
  it('should show loading spinner when clicked', async () => {
    render(<LoginButton onLogin={vi.fn()} />);

    await userEvent.click(screen.getByRole('button', { name: /login/i }));

    expect(screen.getByRole('progressbar')).toBeInTheDocument();
  });
});

API 端点（Supertest）

import request from 'supertest';
import { app } from '../app';

describe('POST /api/analyze', () => {
  it('should return 401 without authentication', async () => {
    const response = await request(app)
      .post('/api/analyze')
      .send({ data: 'test' });

    expect(response.status).toBe(401);
    expect(response.body.error).toBe('Unauthorized');
  });
});

异步代码

describe('fetchUserData', () => {
  it('should retry 3 times on network failure', async () => {
    const mockFetch = vi.fn()
      .mockRejectedValueOnce(new Error('Network'))
      .mockRejectedValueOnce(new Error('Network'))
      .mockResolvedValueOnce({ id: 1, name: 'Test' });

    const result = await fetchUserData(1, { fetch: mockFetch });

    expect(mockFetch).toHaveBeenCalledTimes(3);
    expect(result.name).toBe('Test');
  });
});

违反 TDD 时

1. 停止：没有测试时，不再生成代码
2. 警告：「检测到 TDD 违规：[描述]」
3. 指导：展示正确的 TDD 工作流
4. 询问：「要我先编写测试吗？」

成功衡量指标

• 测试与代码比例：至少为 1:1（测试代码行数与代码行数之比）
• 覆盖率：新代码至少达到 80%
• 红绿周期：周期短（每项功能 5–10 分钟）
• 测试执行时间：单元测试在 10 秒内完成

命令

# Einzelnen Test laufen lassen (RED pruefen)
npm run test -- --run path/to/file.test.ts

# Alle Tests (vor Commit)
npm run test

# Coverage Report
npm run test:coverage

# Watch Mode (waehrend Entwicklung)
npm run test -- --watch

与其他技能集成

• code-quality-gate：TDD 测试是 Gate 1（提交前检查）的一部分
• strict-typescript-mode：测试也必须具有类型安全性
• supervisor：审查 Agent 验证是否遵循 TDD

来源与延伸阅读

• Kent Beck：《Test-Driven Development: By Example》
• Robert C. Martin：《Clean Code》（第 9 章：单元测试）
• Martin Fowler：《Refactoring》（重构时的测试安全性）