tdd-workflow

name	tdd-workflow
description	TDD 方法论和测试策略。当开发新功能、修复 bug 或重构代码时使用此技能。

TDD 工作流技能

确保所有代码开发遵循 TDD 原则，达到全面的测试覆盖率。

激活条件

• 开发新功能
• 修复 Bug
• 重构代码
• 创建 API 端点
• 创建新组件

核心原则

1. 测试先于代码

总是先写测试，再写实现代码。

2. 覆盖率要求

• 最低 80% 覆盖率（单元 + 集成 + E2E）
• 覆盖所有边界情况
• 测试错误场景
• 验证边界条件

3. 测试类型

单元测试

• 独立函数和工具
• 组件逻辑
• 纯函数
• 辅助工具

集成测试

• API 端点
• 数据库操作
• 服务交互
• 外部 API 调用

E2E 测试（Playwright）

• 关键用户流程
• 完整工作流
• 浏览器自动化
• UI 交互

TDD 工作流步骤

步骤 1: 编写用户旅程

作为 [角色]，我想要 [操作]，以便 [收益]

示例：
作为用户，我想要语义搜索市场，
以便即使没有精确关键词也能找到相关市场。

步骤 2: 生成测试用例

为每个用户旅程创建全面的测试用例：

describe('语义搜索', () => {
  it('返回相关市场', async () => {
    // 测试实现
  })

  it('优雅处理空查询', async () => {
    // 测试边界情况
  })

  it('按相似度排序结果', async () => {
    // 测试排序逻辑
  })
})

步骤 3: 运行测试（应该失败）

npm test
# 测试应该失败 - 还没实现

步骤 4: 实现代码

编写最少代码使测试通过

步骤 5: 再次运行测试

npm test
# 测试现在应该通过

步骤 6: 重构

保持测试通过的同时改进代码质量

步骤 7: 验证覆盖率

npm run test:coverage
# 验证达到 80%+ 覆盖率

常见测试错误

❌ 错误: 测试实现细节

expect(component.state.count).toBe(5)

✅ 正确: 测试用户可见行为

expect(screen.getByText('Count: 5')).toBeInTheDocument()

最佳实践

1. 先写测试 - 总是 TDD
2. 每测试一个断言 - 专注单一行为
3. 描述性测试名称 - 说明测试内容
4. Arrange-Act-Assert - 清晰的测试结构
5. 模拟外部依赖 - 隔离单元测试
6. 测试边界情况 - null、undefined、空、大值
7. 测试错误路径 - 不仅仅是正常路径
8. 保持测试快速 - 单元测试 <50ms