GSD「add-tests」命令实战：为已完成阶段自动生成并提交单元测试与 E2E 测试

GSD「add-tests」命令实战为已完成阶段自动生成并提交单元测试与 E2E 测试【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done导读/gsd:add-tests是 get-shit-doneGSD系统中面向已完成阶段的测试生成命令。它不再要求开发者手工拼写/gsd:quick提示词去补测试而是以该阶段沉淀的SUMMARY.md、CONTEXT.md、VERIFICATION.md为规格书自动完成「变更文件分类 → 分类确认 → 测试结构探测 → 测试计划审批 → RED-GREEN 执行 → 覆盖率差距报告 → 提交」的全流程。读完本文你将掌握该命令的参数契约、TDD/E2E/Skip 三类文件的判定标准、两道人工审批门分类审批、计划审批的运作方式以及它如何在不篡改实现的前提下把测试失败转化为 Bug 报告。一、命令定位它解决什么问题GSD 是一个规范驱动开发系统其工作流文档 get-shit-done/workflows/add-tests.md 明确写到此前开发者往往在每个阶段之后手工拼接/gsd:quick提示词来生成测试过程缺乏一致性。add-tests正是为此标准化的产物以阶段工件为唯一规格来源而不是凭记忆或猜测提供显式的三分类机制TDD / E2E / Skip避免文件名像什么就测什么的随意性设置质量门禁分类需审批、测试计划需审批、所有测试必须真实执行且不许把未运行的测试标记为通过输出覆盖率差距与 Bug 发现报告并把通过的测试用规范化的 Conventional Commit 信息提交。命令的核心目的来自 commands/gsd/add-tests.md 的objective可概括为为已完成的阶段生成单元测试与端到端测试产出物是一批测试文件并以固定消息test(phase-{N}): add unit and E2E tests from add-tests command提交。二、命令契约参数与执行上下文2.1 Frontmatter 契约命令文件头部定义了完整的机器可读契约字段值含义namegsd:add-tests命令标识按gsd:命名空间注册descriptionGenerate tests for a completed phase based on UAT criteria and implementation面向 Agent 的能力描述argument-hintphase [additional instructions]参数形态提示requires[phase]声明该命令必须携带阶段参数allowed-toolsRead / Write / Edit / Bash / Glob / Grep / Agent / AskUserQuestion命令执行期间允许使用的工具集其中的requires: [phase]约束并非装饰性内容SDK 会解析命令 frontmatter 中的requires并据此做前置校验参见安装侧测试 tests/runtime-artifact-layout-install-profiles.test.cjs其断言m.has(add-tests)且解析出的 requires 精确等于[phase]。也就是说缺少阶段参数时该命令在契约层面就是不完整的。allowed-tools的选取也透露出执行策略读写靠Read/Write/Edit探测测试结构与运行测试依赖Bash/Glob/Grep需要推理归纳时允许派生Agent两处人工确认则交给AskUserQuestion。2.2 执行上下文与阶段工件命令执行时会加载两类上下文工作流本体~/.claude/get-shit-done/workflows/add-tests.md即仓库内的 get-shit-done/workflows/add-tests.md命令文档通过execution_context指回该工作流规划状态.planning/STATE.md 与 .planning/ROADMAP.md用于确定当前所处阶段与整体路线。2.3 参数解析命令只接收一个必填位置参数——阶段号支持整数、小数或字母后缀如2、2.5、2a阶段号之后的所有文本被作为附加指令传递/gsd:add-tests 12 /gsd:add-tests 12 focus on edge cases in the pricing module参数解析为$PHASE_ARG与可选的$EXTRA_INSTRUCTIONS两个变量。缺少阶段号时命令打印ERROR: Phase number required及用法示例后退出。用户文档 docs/COMMANDS.md 中登记的命令形式为/gsd-add-tests 2与斜杠形式等价。三、核心流程六步走命令文档的process与工作流文档中的process步骤一一对应完整流程如下。3.1 初始化加载阶段操作上下文命令首先调用 SDK 查询初始化阶段操作上下文INIT$(gsd-sdk query init.phase-op ${PHASE_ARG}) if [[ $INIT file:* ]]; then INIT$(cat ${INIT#file:}); fi从返回的 JSON 中提取phase_dir、phase_number、phase_name三个字段。init.phase-op是 SDK 查询热路径中的既有能力在 sdk/src/query/command-family-handlers.ts 中注册分派到initPhaseOp处理器。阶段目录不存在时报错并要求确认$ARGUMENTS阶段存在于.planning/phases/。随后按优先级读取阶段工件{phase_dir}/*-SUMMARY.md——本阶段实现了什么、改动了哪些文件{phase_dir}/CONTEXT.md——验收标准与决策记录{phase_dir}/*-VERIFICATION.md——若做过 UAT则包含用户已人工验证的场景。其中SUMMARY.md 是硬前提缺失时报错No SUMMARY.md found for phase N提示本命令面向已完成阶段请先运行 /gsd:execute-phase。也就是说add-tests永远位于execute-phase之后属于阶段生命周期的收尾动作这也解释了为何它要和verify-work、extract-learnings等命令配合使用。初始化成功后展示横幅━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GSD ► ADD TESTS — Phase {phase_number}: {phase_name} ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3.2 分析实现三分类判定从 SUMMARY.md 的 Files Changed 段落提取变更文件清单逐个读文件做分类明确禁止只凭文件名下结论Read each file to verify classification. Dont classify based on filename alone.。分类规则如下表分类判定标准测试类型TDD可以写出expect(fn(input)).toBe(output)的纯函数单元测试E2E可由浏览器自动化验证的 UI 行为Playwright / E2E 测试Skip无意义可测性或已被覆盖无应判为 TDD单元测试的典型对象业务逻辑计算、定价、税率规则、校验数据变换映射、过滤、聚合、格式化解析器CSV / JSON / XML / 自定义格式解析校验器输入校验、schema 校验、业务规则状态机状态流转、工作流步骤工具函数字符串处理、日期处理、数字格式化。应判为 E2E浏览器测试的典型对象键盘快捷键按键绑定、修饰键、和弦序列导航页面跳转、路由、面包屑、前进/后退表单交互提交、校验错误、字段聚焦、自动补全选择行为行选择、多选、Shift 点击范围选择拖放重排序、跨容器移动模态对话框打开、关闭、确认、取消数据表格排序、过滤、行内编辑、列宽调整。应判为 Skip 的典型对象UI 布局/样式CSS 类、视觉外观、响应式断点配置类配置文件、环境变量、功能开关胶水代码依赖注入装配、中间件注册、路由表数据库迁移与 schema 变更无业务逻辑的简单 CRUD无逻辑的类型定义record、DTO、interface。3.3 展示分类并征求确认第一道门分类完成后必须把结果呈现给用户并取得批准不能直接进入生成。这是本命令与闷头写测试式 Agent 行为的本质区别。多运行时兼容当配置中workflow.text_mode: true或$ARGUMENTS中带有--text标记时TEXT_MODE被激活所有AskUserQuestion都退化为纯文本编号列表 让用户输入选项序号。这是为 OpenAI Codex、Gemini CLI 等未提供AskUserQuestion的非 Claude 运行时准备的必需路径。确认对话框呈现三组清单每组附文件与简要理由并提供三个选项Approve and generate test plan——批准并进入测试计划阶段Adjust classification——用户给出调整后重新展示Cancel——优雅退出。3.4 探测既有测试结构在生成测试计划之前命令会先用 shell 探测项目现有的测试约定而不是凭空假设find . -type d -name *test* -o -name *spec* -o -name *__tests__* 2/dev/null | head -20 find . -type f \( -name *.test.* -o -name *.spec.* -o -name *Tests.fs -o -name *Test.fs \) 2/dev/null | head -20 ls package.json *.sln 2/dev/null || true需要识别四件事测试目录结构单元/E2E 各自存放位置、命名约定.test.ts、.spec.ts、*Tests.fs等、测试运行命令、测试框架xUnit、NUnit、Jest、Playwright 等。若发现多个候选位置且难以判定则通过AskUserQuestion询问用户在何处创建测试。3.5 生成测试计划并审批第二道门对每个批准的文件制定详细测试计划TDD 文件按 RED-GREEN-REFACTOR 规划先找出文件内可测函数再为每个函数列出输入场景、期望输出与边界用例。工作流特别提醒由于代码已存在测试可能立刻通过——这没问题但必须确认测试验证的是正确行为而非仅仅能编译。E2E 文件按 RED-GREEN 门禁规划从 CONTEXT.md / VERIFICATION.md 提取用户场景为每个场景写明用户动作、期望结果与断言。这里的 RED 门含义是确认当功能被破坏时该测试确实会失败即测试要有真实杀伤力。随后展示完整测试计划其中包含每个测试文件路径与用例清单以及探测到的运行命令段落内容Unit Tests{N} tests across {M} files逐文件列用例E2E Tests{P} tests across {Q} files逐文件列场景Test CommandsUnit 与 E2E 各自的发现命令选项为Generate all全部生成、Cherry-pick用户指定生成哪些、Adjust plan修改后重新展示。3.6 执行生成RED-GREEN 全流程TDD 测试生成遵循写测试 → 跑测试 → 分诊结果三段式按项目既有约定创建测试文件目录、命名、导入以清晰的 Arrange/Act/Assert 三段结构编写测试// Arrange — set up inputs and expected outputs // Act — call the function under test // Assert — verify the output matches expectations运行测试并分诊结果通过说明实现满足测试但需确认测试在验证有意义的行 为断言失败可能是测试发现真 Bug按如下模板标记绝不修改实现this is a test-generation command, not a fix command只记录发现⚠️ Potential bug found: {test name} Expected: {expected} Actual: {actual} File: {implementation file}错误失败导入、语法等属于测试自身错误修复测试后重跑。E2E 测试生成与之类似但多出两道防线先检查既有测试是否已覆盖同类场景对场景关键词grep命中则扩展现有测试而非重复造轮子运行结果分诊为 GREEN记录成功、RED判定是测试问题还是真 BugBug 按模板标记、Cannot run报告阻塞禁止标记完成。工作流文档中特别写明No-skip ruleIf E2E tests cannot execute (missing dependencies, environment issues), report the blocker and mark the test as incomplete. Never mark success without actually running the test.——这一条把诚实报告写成了硬性纪律从机制上杜绝了假绿。四、收尾覆盖率报告、状态记录与提交4.1 结果汇报所有测试执行完毕后命令输出覆盖报告横幅其中包含结构化结果表格━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GSD ► TEST GENERATION COMPLETE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ## Results | Category | Generated | Passing | Failing | Blocked | |----------|-----------|---------|---------|---------| | Unit | {N} | {n1} | {n2} | {n3} | | E2E | {M} | {m1} | {m2} | {m3} | ## Files Created/Modified {list of test files with paths} ## Coverage Gaps {areas that couldnt be tested and why} ## Bugs Discovered {any assertion failures that indicate implementation bugs}其中Coverage Gaps无法覆盖的区域及原因和Bugs Discovered暗示实现缺陷的断言失败是手工补测试时常被忽略、而本命令强制显式化的输出。4.2 状态记录与提交先通过 SDK 查询快照并记录测试生成动作到项目状态gsd-sdk query state-snapshot若存在通过的测试则暂存测试文件并以规范消息提交git add {test files} git commit -m test(phase-${phase_number}): add unit and E2E tests from add-tests command注意提交消息前缀test(phase-N)与 docs/COMMANDS.md 所载的 Conventional Commits 风格保持一致便于后续按阶段回放与审计。4.3 下一步引导报告末尾按结果分派后续动作发现 Bug提示/gsd:quick fix the {N} test failures discovered in phase {N}存在阻塞测试提示解决阻塞的具体条件全部通过宣告Phase N is fully tested。同时给出两条快捷路径/gsd:add-tests {next_phase}测试下一阶段、/gsd:verify-work {phase_number}对当前阶段执行 UAT 验证。五、可验证的成功标准工作流末尾定义了一组勾选式成功标准任何一次执行都应逐项满足。它同时也是测试该命令实现时的行为规格阶段工件已加载SUMMARY.md、CONTEXT.md必要时 VERIFICATION.md所有变更文件已分类为 TDD / E2E / Skip分类已向用户展示并获批项目测试结构已探测目录、命名约定、运行器测试计划已展示并获批TDD 测试按 arrange/act/assert 结构生成E2E 测试面向用户场景生成所有测试均已真实执行——不存在未运行却标记通过的测试测试发现的 Bug 已被标记而非修复测试文件以正确消息提交覆盖率差距已文档化下一步动作已呈现。六、设计要点小结结合 commands/gsd/add-tests.md 与 get-shit-done/workflows/add-tests.md可以提炼出这套测试生成机制区别于一般AI 写测试脚本的四个设计原则供你在自己的阶段工作流中复用文档即规格测试场景不来自 Agent 的想象而来自阶段沉淀的 SUMMARY/CONTEXT/VERIFICATION 三类工件保证测的是当初承诺的验收标准。双门人工审批分类确认与测试计划确认各设一道AskUserQuestion门把生成什么的决策权交还开发者Agent 只负责执行与报告。强制真实执行No-skip rule 与不许标记未运行测试为通过相互配合杜绝纸面绿。测试只发现、不修复断言失败一律标记为 Bug 并以规范模板上报修复交由/gsd:quick等修复路径处理保持了命令职责单一single responsibility避免测试生成命令越界改动实现代码。如果你正在为一个 GSD 阶段收尾典型调用链是/gsd:execute-phase N完成实现 →/gsd:add-tests N依据阶段工件补齐单元与 E2E 测试并提交 → 若测试报告了 Bug 则/gsd:quick fix ...修复 → 最后用/gsd:verify-work N做人工 UAT 复核。这套链路让测试补全从凭感觉的散活变成了可分类、可审批、可执行、可审计的规范化流程。【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考