mcpField
T
tcrdd

tcrdd

github.com/bsene测试与质量7182 次安装1 周前更新
代码仓库

关于 tcrdd

tcrdd 是一项通过原生 Git 执行红灯/绿灯/重构的技能,将工作拆分为小步测试驱动阶段。它会暂存更改、运行测试,并按结果提交或回退每个阶段,同时覆盖交互式和无人值守流程。

主要功能

  1. 01每阶段只推进一小步
  2. 02依据实际测试结果决策
  3. 03自动提交或回退
  4. 04支持交互与无人值守模式
  5. 05失败日志与恢复指引

适用场景

  1. 01逐步进行测试驱动开发
  2. 02在无人审批时运行编码任务
  3. 03避免测试失败后遗留部分更改

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/bsene/skills --skill tcrdd

安装后在 Claude Code 中输入/tcrdd确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

references/
autonomous-execution.md
benchmarks.md
example-and-errors.md
further-reading.md
git-cycle.md
phase-guide.md
pragmatics.md

详细介绍

TCRDD

由原生 Git 驱动的红/绿/重构流程:每个阶段都会暂存更改、运行测试,并在结果符合预期时自动提交,否则自动还原(git reset --hard)。无需外部工具。

前置条件:从干净的工作树开始——没有未提交的更改,也没有未跟踪的文件。 还原操作(git add -A + git reset --hard)会删除未跟踪的文件,且无法通过 reflog 恢复,因此在循环开始时存在的任何未跟踪文件都会丢失。请在第一次执行 add -A 前,将想要保留的文件存入 git stash -u(或专用 worktree)。

模式

  • 交互式(有人参与):使用以下审批关卡——先审批计划,再在每次暂存并运行测试前审批差异。
  • 自主式(没有人可审批,例如无人值守运行):直接运行循环。 审批关卡可选——跳过并继续即可。仍需按阶段提交,每次仍只迈出一小步。不要停下来等待永远不会到来的审批。

关键防护措施

  • 在宣布 RED/GREEN 或提交前,检查实际的完整测试运行结果。绝不要根据预测推进。
  • 每个阶段只迈出一小步,包括无人值守运行;绝不要批量执行完整测试套件或实现。
  • 测试前使用 git add -A 暂存,以便失败的步骤也能还原新文件。重置前记录失败详情,然后追加到 tcr-failure-log.md,并在重置后单独提交该日志。执行阶段前请阅读Git 循环。
  • 只解析一次仓库的测试命令(按顺序检查包脚本、Makefile、语言惯例,然后是 README/CI,或询问用户);除非用户明确限定范围,否则每个阶段都重复运行完整 CI 测试套件。
  • 自主运行:设定预算,并发 Agent 使用隔离的 worktree,为阶段提交添加标签,并在预算用尽时停止。同一步骤还原超过两次后,将其拆分;如果再次拆分后仍停滞,则停止并报告阻碍。有关必需的结构化交接,请遵循自主执行。
  • 仅对简单代码、GUI 布局调整、可信的第三方内部实现或确实会丢弃的工作跳过或降级处理。对持久的 GUI 逻辑进行提取并使用 TCRDD;在第三方边界测试自己的代码。有关例外和严格限制,请阅读实用性指南。

工作流

GREEN:只编写通过当前失败测试所需的最少代码。 不要泛化,也不要处理未来的情况;使用下方编号最低的转换。

RED   → plan test → approval? → write test → diff approval? → stage + run tests
        test FAILS (expected)?   commit [RED]      → GREEN
        test PASSES (unexpected)? log → reset --hard → try again

GREEN → plan code → approval? → write code → diff approval? → stage + run tests
        tests PASS?  commit [GREEN]      → REFACTOR
        tests FAIL?  log → reset --hard  → try again

REFACTOR → plan cleanup → approval? → refactor → diff approval? → stage + run tests
           tests PASS (no behaviour change)? commit [REFACTOR]     → (loop or done or back to RED)
           tests FAIL?                       log → reset --hard   → try again

如何编写代码

每个阶段开始前(仅交互模式):用户先审批计划,然后在暂存和运行测试前审批差异。

一次只做一步——绝不一次性完成。 每个阶段只推进一小步:先编写一个失败测试,再编写通过该测试所需的最少代码。不要一次性写完整测试套件或完整实现,即使在自主模式下也不行。如果你在一轮中就产出完整功能,说明你没有运行 TCRDD。

  • RED——选择下一个最小行为;只编写足以使测试失败的内容(遇到第一个编译错误或断言失败时就停止)。
  • GREEN——为当前失败测试编写最少的生产代码;不添加额外的辅助代码、依赖或未来情况处理。使用转换阶梯上编号最低的操作;如果需要使用编号较高的操作,说明测试过大,应将其拆分。
  • REFACTOR——所有测试通过后,自由清理生产代码和测试代码。
  • REPEAT——询问功能是否已完成:未完成则回到 RED;已完成则将中间提交压缩为一个干净的提交。

详情、完整的 12 步阶梯、小步与一次性完成的示例,以及错误处理表,请参阅下方的参考资料。

按需阅读

何时阅读链接
编写 RED/GREEN/REFACTOR 阶段或选择转换方式时阶段指南
查看一个小步示例,或遇到回滚、测试不稳定或工作树不干净的情况时示例与错误
无人值守运行或向编排器汇报时自主执行
实现暂存/测试/提交/回滚和故障日志时Git 周期
决定是否跳过或降低循环要求时实用建议
了解 TCR/TDD/TPP 理论和原始文章(Beck、Uncle Bob)时延伸阅读
查看基准测试结果时基准测试

上游

开始 TCRDD 前技能原因
不确定是否值得构建此功能kano在投入红/绿/重构循环前对功能进行分类

评论

支持 Markdown