SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场tdd-workflow

tdd-workflow

测试与质量

查看项目

更新于 10-15 08:33

技能介绍

用途

tdd-workflow 用于在开发过程中强制执行测试驱动开发（TDD）原则，确保代码具备全面的测试覆盖。它适用于以下场景：编写新功能或新特性、修复缺陷或问题、重构现有代码、添加 API 端点、创建新组件。

核心原则

  1. 测试先于代码：始终先编写测试，再实现代码使测试通过。
  2. 覆盖率要求：最低 80% 覆盖率（单元 + 集成 + E2E），覆盖所有边界条件、错误场景与边界值。
  3. 测试类型：
    • 单元测试：单个函数与工具、组件逻辑、纯函数、辅助工具。
    • 集成测试：API 端点、数据库操作、服务交互、外部 API 调用。
    • E2E 测试（Playwright）：关键用户流程、完整工作流、浏览器自动化、UI 交互。
  4. Git 检查点：若仓库处于 Git 管理下，每个 TDD 阶段后创建检查点提交；在工作流完成前不要压缩或重写这些检查点提交；每个检查点提交信息必须描述阶段与所捕获的确切证据；只统计当前活动分支上为当前任务创建的提交；在将检查点视为满足前，需验证该提交可从活动分支的当前 HEAD 到达且属于当前任务序列。推荐的紧凑工作流为：一次提交用于添加失败测试并验证 RED；一次提交用于应用最小修复并验证 GREEN；一次可选提交用于完成重构。如果测试提交明确对应 RED、修复提交明确对应 GREEN，则无需单独的仅证据提交。

TDD 工作流步骤

步骤 1：编写用户旅程。格式为“作为[角色]，我想要[动作]，以便[收益]”。

步骤 2：生成测试用例。为每个用户旅程创建全面的测试用例，包括正常路径、边界情况、回退行为、排序逻辑等。

步骤 3：运行测试（应当失败）。执行 npm test，测试应当失败，因为尚未实现。此步骤为强制步骤，是所有生产变更的 RED 门禁。在修改业务逻辑或其他生产代码前，必须通过以下路径之一验证有效的 RED 状态：

  • 运行时 RED：相关测试目标编译成功；新增或变更的测试实际被执行；结果为 RED。
  • 编译时 RED：新测试新实例化、引用或执行了有缺陷的代码路径；编译失败本身即为预期的 RED 信号。 无论哪种情况，失败必须由预期的业务逻辑缺陷、未定义行为或缺失实现引起，而不能仅由无关的语法错误、损坏的测试设置、缺失依赖或无关回归引起。仅编写但未编译执行的测试不算 RED。在确认此 RED 状态前，不要编辑生产代码。若仓库处于 Git 管理下，在此阶段验证后立即创建检查点提交，推荐提交信息格式为：test: add reproducer for <feature or bug>。此提交也可作为 RED 验证检查点（若复现器已编译执行并因预期原因失败）。继续前验证该检查点提交位于当前活动分支。

步骤 4：实现代码。编写最小代码使测试通过。若仓库处于 Git 管理下，现在暂存最小修复，但将检查点提交推迟到步骤 5 验证 GREEN 之后。

步骤 5：再次运行测试。修复后重新运行同一相关测试目标，确认先前失败的测试现在为 GREEN。只有在获得有效 GREEN 结果后，才可进行重构。若仓库处于 Git 管理下，在验证 GREEN 后立即创建检查点提交，推荐提交信息格式为：fix: <feature or bug>。此修复提交也可作为 GREEN 验证检查点（若同一相关测试目标已重新运行并通过）。继续前验证该检查点提交位于当前活动分支。

步骤 6：重构。在保持测试通过的前提下改进代码质量：消除重复、改进命名、优化性能、增强可读性。若仓库处于 Git 管理下，在重构完成且测试保持通过后立即创建检查点提交，推荐提交信息格式为：refactor: clean up after <feature or bug> implementation。在认为 TDD 循环完成前，验证该检查点提交位于当前活动分支。

步骤 7：验证覆盖率。运行 npm run test:coverage，验证达到 80% 以上覆盖率。

测试模式

单元测试模式（Jest/Vitest）：使用 @testing-library/react 渲染组件，断言文本、点击回调、禁用状态等。

API 集成测试模式：使用 NextRequest 构造请求，调用 GET 处理函数，断言状态码、响应数据结构、参数校验与数据库错误处理。

E2E 测试模式（Playwright）：导航页面、点击链接、填写输入、等待防抖与结果、断言结果数量与内容、过滤状态、创建市场并验证成功消息与重定向。

测试文件组织

按组件、API 路由与 e2e 目录组织测试文件，例如组件目录下放置 Button.tsx、Button.test.tsx、Button.stories.tsx；API 路由目录下放置 route.ts 与 route.test.ts；e2e 目录下放置 markets.spec.ts、trading.spec.ts、auth.spec.ts。

模拟外部服务

提供 Supabase、Redis、OpenAI 的 jest.mock 示例，用于隔离单元测试。

覆盖率验证

运行 npm run test:coverage，并在配置中设置全局阈值：branches、functions、lines、statements 均为 80。

常见测试错误

避免测试实现细节（应测试用户可见行为）、避免脆弱选择器（应使用语义选择器或 data-testid）、避免测试间无隔离（每个测试自行准备数据）。

持续测试

开发时使用 watch 模式（npm test -- --watch）；提交前钩子运行 npm test && npm run lint；CI/CD 集成中运行 npm test -- --coverage 并上传覆盖率。

最佳实践

始终 TDD 先写测试；每个测试一个断言；描述性测试名称；Arrange-Act-Assert 结构；模拟外部依赖；测试边界情况（null、undefined、空、大值）；测试错误路径；保持测试快速（单元测试每个 < 50ms）；测试后清理；审查覆盖率报告。

成功指标

达到 80% 以上代码覆盖率；所有测试通过（绿色）；无跳过或禁用测试；测试执行快速（单元测试 < 30s）；E2E 测试覆盖关键用户流程；测试在生产前捕获缺陷。

限制

资料未提供该技能的具体安装命令、支持的编程语言范围、与特定框架的绑定关系、收费方式或平台限制等信息。