⚠️

重要前提

安装AI Skills的关键前提是：必须科学上网，且开启TUN模式，这一点至关重要，直接决定安装能否顺利完成，在此郑重提醒三遍：科学上网，科学上网，科学上网。查看完整安装教程 →

严格测试驱动开发(TDD)实践指南：红绿重构循环与13个无效借口解析

tdd-strict by svenja-dev/claude-code-skills

47 周安装量

32 GitHub Stars

GitHub

安装命令

npx skills add https://github.com/svenja-dev/claude-code-skills --skill tdd-strict

方法论代码质量测试

🇨🇳中文介绍

严格的测试驱动开发

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

"如果你没有看到测试失败，你就不知道它是否测试了正确的东西。"

何时启用

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

红-绿-重构循环

1. 红：编写失败的测试

// 首先：编写测试
describe('calculateOEE', () => {
  it('should return 0 when availability is 0', () => {
    const result = calculateOEE({ availability: 0, performance: 100, quality: 100 });
    expect(result).toBe(0);
  });
});

// 测试必须失败：
// Error: calculateOEE is not defined
// 或
// Error: Expected 0 but received undefined

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

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

2. 绿：使测试通过的最小代码

// 然后：最小代码
export function calculateOEE(params: OEEParams): number {
  if (params.availability === 0) return 0;
  // 更多逻辑稍后通过更多测试添加
  return 0;
}

：编写使测试通过的最简单代码。

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

3. 重构：清理而不添加新行为

// 经过多个绿色测试后：允许重构
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. "模拟太麻烦了"

现实：如果模拟太复杂，那么设计就太复杂了。重构。

每次提交前必须满足：

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

实践中的 TDD 工作流

步骤 1：创建测试文件

# 对于 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

# 预期输出：
# Error: Cannot find module './oee'
# 或存根后：
# 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

# 预期输出：
# 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（红）-> 步骤 4（绿）-> 重复。

禁止：先写代码后写测试

// 错误：先写代码
function add(a: number, b: number): number {
  return a + b;
}

// 然后才写测试 - 无效！
// 你不知道测试是否正确

禁止：一次写太多代码

// 错误：在没有测试的情况下实现完整类
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) { ... }
}

// 正确：使用 TDD 逐个方法实现

禁止：修改测试使其通过

// 错误：因为实现不同而修改测试
// 之前：expect(result).toBe(100);
// 之后：expect(result).toBe(99.5); // "因为公式这样输出"

// 正确：修正实现或澄清需求

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 违规：[描述]"
指导：展示正确的 TDD 工作流
提问："我应该先写测试吗？"

测试代码比：至少 1:1（测试代码行数与代码行数）
覆盖率：新代码至少 80%
红绿时间：短周期（每个功能 5-10 分钟）
测试执行时间：单元测试少于 10 秒

# 运行单个测试（验证红）
npm run test -- --run path/to/file.test.ts

# 所有测试（提交前）
npm run test

# 覆盖率报告
npm run test:coverage

# 监视模式（开发期间）
npm run test -- --watch

与其他技能的集成

code-quality-gate：TDD 测试是门禁 1 的一部分（提交前）
strict-typescript-mode：测试也必须是类型安全的
supervisor：检查代理验证 TDD 合规性

来源和延伸阅读

Kent Beck：《测试驱动开发：示例》
Robert C. Martin：《代码整洁之道》（第 9 章：单元测试）
Martin Fowler：《重构》（重构时的测试安全性）

🇺🇸English

Striktes Test-Driven Development

Dieser Skill erzwingt TDD-Praktiken basierend auf dem Kernprinzip:

"If you didn't watch the test fail, you don't know if it tests the right thing."

Wann aktivieren

Bei jeder neuen Feature-Implementierung
Bei Bug Fixes (erst Test der Bug reproduziert, dann Fix)
Bei Refactoring (Tests muessen vor UND nach Aenderung bestehen)
Bei API-Erweiterungen
Bei jeder exportierten Funktion

Der Red-Green-Refactor Zyklus

1. RED: Test schreiben der fehlschlaegt

// 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

Wichtig : Der Test MUSS aus dem richtigen Grund fehlschlagen:

Funktion existiert nicht
Funktion gibt falsches Ergebnis zurueck
NICHT: Syntaxfehler im Test selbst

2. GREEN: Minimaler Code der Test besteht

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

Regel : Schreibe den EINFACHSTEN Code der den Test besteht.

Keine Optimierungen
Keine zusaetzlichen Features
Keine "offensichtlichen" Erweiterungen

3. REFACTOR: Bereinigen ohne neues Verhalten

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

Regeln fuer Refactoring :

Alle bestehenden Tests MUESSEN bestehen bleiben
KEIN neues Verhalten hinzufuegen
Nur Code-Struktur verbessern
Nach jedem Refactoring-Schritt: Tests laufen lassen

Die 13 ungueltigen Rationalisierungen

Diese Ausreden sind NIEMALS akzeptabel:

1. "Zu einfach zum Testen"

Realitaet : Einfacher Code braucht einfache Tests. 1 Zeile Test ist okay.

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

2. "Ich teste spaeter"

Realitaet : "Spaeter" bedeutet "nie". TDD bedeutet Test ZUERST.

3. "Bereits manuell getestet"

Realitaet : Manuelle Tests sind nicht reproduzierbar und skalieren nicht.

4. "Zeitdruck erlaubt keine Tests"

Realitaet : Tests sparen Zeit bei Debugging und verhindern Regressionen.

5. "Private Methoden muss man nicht testen"

Realitaet : Teste das Verhalten durch Public APIs. Wenn nicht testbar: Refactor.

6. "UI-Code kann man nicht testen"

Realitaet : React Testing Library, Playwright, Storybook existieren genau dafuer.

7. "Die Logik ist trivial"

Realitaet : Triviale Logik aendert sich. Tests dokumentieren erwartetes Verhalten.

8. "Wir haben einen QA-Prozess"

Realitaet : QA findet Bugs spaeter und teurer. TDD verhindert Bugs von Anfang an.

9. "Der Code ist nur temporaer"

Realitaet : Temporaerer Code lebt oft Jahre. Tests sichern auch temporaeren Code ab.

10. "Tests verlangsamen die Entwicklung"

Realitaet : TDD beschleunigt langfristig durch weniger Debugging und Regressionen.

11. "Legacy Code hat keine Tests"

Realitaet : Charakterisierungstests vor Aenderungen schreiben. Schrittweise verbessern.

12. "Das Framework/die Library testet das schon"

Realitaet : Teste DEINE Nutzung des Frameworks, nicht das Framework selbst.

13. "Mocking ist zu aufwaendig"

Realitaet : Wenn Mocking zu komplex ist, ist das Design zu komplex. Refactor.

Verification Checklist

Vor jedem Commit MUSS gelten:

Jede exportierte Funktion hat mindestens einen Test
Jeder Test ist VOR der Implementation fehlgeschlagen (RED beobachtet)
Jeder Test prueft genau EINE Sache (Single Assertion Principle)
Minimaler Code pro Test (kein Over-Engineering)
Edge Cases abgedeckt:
- Null/Undefined Inputs
- Leere Arrays/Strings
- Grenzwerte (0, MAX_INT, negative Zahlen)
- Fehlerhafte Inputs (TypeError erwartet)
Test-Namen beschreiben Verhalten: should [erwartetes Ergebnis] when [Bedingung]
Keine skip oder only Tests im Commit
Coverage mindestens 80% fuer neuen Code

TDD-Workflow in der Praxis

Schritt 1: Test-Datei erstellen

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

Schritt 2: Minimaler fehlschlagender Test

// 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);
  });
});

Schritt 3: Test laufen lassen (MUSS fehlschlagen)

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

Schritt 4: Minimale Implementation

// 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;
}

Schritt 5: Test laufen lassen (MUSS bestehen)

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

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

Schritt 6: Naechster Test fuer Edge Case

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

Zurueck zu Schritt 3 (RED) -> Schritt 4 (GREEN) -> Repeat.

Anti-Patterns erkennen

VERBOTEN: Test nach Code

// 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

VERBOTEN: Zu viel Code auf einmal

// 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

VERBOTEN: Tests anpassen damit sie bestehen

// 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

Framework-spezifische Patterns

React Components (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 Endpoints (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');
  });
});

Async Code

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');
  });
});

Bei Verstoß gegen TDD

STOPP : Keine weitere Code-Generierung ohne Test
WARNUNG : "TDD-Verstoß erkannt: [Beschreibung]"
ANLEITUNG : Zeige den korrekten TDD-Workflow
FRAGE : "Soll ich zuerst den Test schreiben?"

Metriken zur Erfolgsmessung

Test-to-Code Ratio : Mindestens 1:1 (Test-LOC zu Code-LOC)
Coverage : Minimum 80% fuer neuen Code
Red-Green Time : Kurze Zyklen (5-10 Minuten pro Feature)
Test Execution Time : Unit Tests unter 10 Sekunden

Kommandos

# 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

Integration mit anderen Skills

code-quality-gate : TDD Tests sind Teil von Gate 1 (Pre-Commit)
strict-typescript-mode : Tests muessen auch Type-safe sein
supervisor : Pruefer-Agent verifiziert TDD-Einhaltung

Quellen und Weiterfuehrende Literatur

Kent Beck: "Test-Driven Development: By Example"
Robert C. Martin: "Clean Code" (Kapitel 9: Unit Tests)
Martin Fowler: "Refactoring" (Test-Sicherheit bei Refactoring)

Weekly Installs

Repository

svenja-dev/clau…e-skills

GitHub Stars

First Seen

Jan 24, 2026

Security Audits

Gen Agent Trust HubPass SocketPass SnykPass

Installed on

opencode43

claude-code41

codex39

gemini-cli39

cursor36

github-copilot34

Vue 3 调试指南：解决响应式、计算属性与监听器常见错误

12,200 周安装