by 运行时依赖
无特殊依赖
安装命令
点击复制官方npx clawhub@latest install gen-test
镜像加速npx clawhub@latest install gen-test --registry https://cn.longxiaskill.com 镜像可用
技能文档
Test Gen：为已有项目生成测试 概述 本 skill 面向代码已存在、需要补充测试的场景（区别于 TDD 先写测试再写代码）。通过五个阶段，从项目理解到测试交付，系统性地为已有项目生成高质量测试。 核心理念： 黑盒优先 — 从函数签名和接口契约出发，不偷看实现 诚实评审 — 设计有问题就直接说，不生成低质量测试来掩盖 覆盖率可量化 — 每次生成后产出覆盖率数据作为质量基线 安装 支持两种安装方式，使用 AskQuestion 让用户选择： 项目级安装（推荐协作项目，跟随 git 提交，团队共享）： mkdir -p .cursor/skills && cp -r /path/to/test-gen .cursor/skills/test-gen # 同时安装斜杠命令 mkdir -p .cursor/commands && cp /path/to/test-gen.md .cursor/commands/test-gen.md 用户级安装（个人全局使用，跨项目可用）： mkdir -p ~/.cursor/skills && cp -r /path/to/test-gen ~/.cursor/skills/test-gen 项目级安装的 skill 优先于用户级。如果两处都存在，项目级生效。 用户级安装时不支持斜杠命令（命令只能放在项目的 .cursor/commands/ 下）。 前置检测 在开始前，自动检测项目环境： 检测清单：
- 语言 — 扫描文件后缀和配置文件（package.json / go.mod / pyproject.toml / pom.xml / Cargo.toml 等）
- 测试框架 — 检查已有依赖（jest / vitest / pytest / go test / JUnit / RSpec 等）
- 已有测试 — 搜索 _test. / .test. / .spec. / test_. 文件
- 覆盖率工具 — 检查是否已配置（nyc / c8 / coverage.py / go cover 等）
- 设计文档 — 搜索 README / ARCHITECTURE / docs/ / DESIGN.md
- 构建系统 — 检查 Makefile / Taskfile / justfile 是否存在
- VCS 状态 — 检查 git 是否可用（用于后续变更行覆盖率）
xxx) 是否立即安装？
详细的安装配方见 coverage-recipes.md。
将检测结果汇报给用户，确认无误后进入覆盖率阈值加载。
覆盖率阈值配置
在前置检测完成后、进入 Phase 1 之前，加载覆盖率阈值。
阈值定义
三层阈值，各自独立判定：
coverage_thresholds:
overall:
# 全项目总体阈值
line: 80
# 行覆盖率 %
branch: 70
# 分支覆盖率 %
function: 80
# 函数覆盖率 %
per_file:
# 单文件阈值（任何单文件不低于此值）
line: 60
branch: 50
delta:
# 变更行覆盖率阈值
line: 90
# 新增/修改的代码行覆盖率
配置来源优先级
按顺序查找，找到即停：
项目配置文件 .test-gen.yaml（项目根目录）
coverage_thresholds:
overall:
line: 85
branch: 75
function: 85
per_file:
line: 70
branch: 60
delta:
line: 95
项目包管理配置中的嵌入字段
Python pyproject.toml：[tool.test-gen.coverage_thresholds]
Node.js package.json："test-gen": { "coverage_thresholds": { ... } }
默认值（上方定义的 80/70/80、60/50、90）
加载后向用户展示当前生效的阈值及来源。
阈值在流程中的使用
Phase 4 步骤 4（全量覆盖率）：将实际值与 overall + per_file 阈值逐项对比
Phase 4 步骤 5（变更行覆盖率）：将实际值与 delta 阈值对比
将阈值传递给底层工具的 --fail-under 参数（如工具支持）
未达标指标在报告中标注 !! NO 并给出与目标的差距
Phase 1: 设计文档分析
目标：理解项目的设计意图、模块划分和数据流。
步骤
搜索设计文档
优先级：ARCHITECTURE.md > DESIGN.md > README.md > docs/ 目录 > 代码注释头
也检查：API 文档（OpenAPI/Swagger）、proto 文件、GraphQL schema
提取关键信息
项目目标和核心功能
模块/包划分及职责
核心数据流（输入 → 处理 → 输出）
外部依赖（数据库、第三方 API、消息队列等）
预期的行为约束和业务规则
无文档时的降级策略
从目录结构推断模块划分
从 import/require 关系推断依赖图
从 package/module 配置推断项目类型
从已有测试推断预期行为
产出项目理解摘要
格式：
项目理解摘要
项目类型 [Web 应用 / API 服务 / CLI 工具 / 库 / ...]
模块划分
| 模块 | 职责 | 核心文件 |
|---|---|---|
外部依赖 [列出所有外部依赖及其用途]
业务规则与约束 [从文档中提取的关键业务规则]
详细指南见 design-analysis-guide.md。 STOP — 与用户确认 使用 AskQuestion 向用户展示项目理解摘要，确认： 模块划分是否准确 是否遗漏了关键模块或业务规则 测试范围的优先级（哪些模块最需要测试） 用户确认后进入 Phase 2。 Phase 2: 函数签名黑盒分析 目标：从公开 API 的角度理解每个函数的契约，不看实现。 铁律 禁止读取函数体。只看签名、类型定义、文档注释。 违反这条规则就失去了黑盒视角，测试会不自觉地追随实现细节。 步骤 识别公开 API 扫描导出的函数、类、方法 排除内部/私有符号（_前缀、unexported、private 等） 关注 Phase 1 中用户标记为高优先级的模块 提取签名信息（仅以下内容） 函数名 参数名和类型 返回值类型 关联的类型/接口定义（struct、interface、type alias） 函数上方的文档注释（doc comment） 是否为 async / 是否抛异常 推断测试维度 对每个函数，基于签名推断： 维度 说明 正常输入 典型合法输入 边界值 空值、零值、最大/最小值、空集合 异常输入 类型不匹配、nil/null/undefined、非法格式 异常路径 基于返回的 error/exception 类型推断 并发安全 如果签名暗示并发使用（channel、mutex、sync 相关） 产出签名清单 按模块分组，每个函数一行：模块: [name]
| 函数 | 参数 | 返回值 | 推断的测试维度 |
|---|---|---|---|