mcpField
P
project-test-loop

project-test-loop

github.com/laurigates测试与质量5964 次安装1 天前更新
代码仓库

关于 project-test-loop

通过确定性 Shell 脚本驱动有上限的测试、修复与重构循环。适用于测试失败时迭代处理，并提供明确的停止条件和测试命令检测。

主要功能

  1. 01自动检测常见测试命令
  2. 02按测试模式筛选运行
  3. 03设置最大循环次数
  4. 04重复失败或设置错误时停止
  5. 05测试通过后进行重构

适用场景

  1. 01以最小改动迭代修复失败测试
  2. 02在项目中运行有上限的 TDD 循环
  3. 03判断测试配置何时需要进一步输入

安装

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

$npx skills add https://github.com/laurigates/claude-plugins --skill project-test-loop

安装后在 Claude Code 中输入/project-test-loop确认已加载。

附带文件scripts/run-test-cycle.shscripts/tests/test-run-test-cycle.sh

详细介绍

/project:test-loop

适用场景

适合使用此技能的场景……适合改用 project-continue 的场景……
驱动 RED -> GREEN -> REFACTOR 循环，直到测试通过继续常规项目工作，且测试并非瓶颈
迭代修复失败的测试，并自动修复和重试会话结束后要总结模式时，改用 project-distill
使用 --max-cycles 限制 TDD 迭代次数，避免循环失控不知道测试命令是什么时，改用 project-discovery

运行自动化 TDD 循环——测试 -> 修复 -> 重构。确定性驱动脚本 （scripts/run-test-cycle.sh）负责每次迭代中的机械操作，你则在每次调用之间进行最小修复。

上下文

  • 项目标记：!find . -maxdepth 1 \( -name package.json -o -name pyproject.toml -o -name pytest.ini -o -name Cargo.toml -o -name go.mod -o -name Makefile \) -print

参数

从 $ARGUMENTS 中解析以下参数：

  • test-pattern（位置参数，可选）——传递给检测到的测试命令的模式，用于聚焦运行范围（例如文件或测试名称筛选条件）。
  • --max-cycles <N>（可选，默认值为 10）——循环上限；循环次数达到 N 时，驱动程序会返回 CAP_REACHED。

如果项目的测试命令配置在 CLAUDE.md / .claude/rules/ 中，且不属于自动检测的命令格式，也可传递 --test-cmd "<command>" 以覆盖自动检测结果。

执行

执行此 TDD 循环。每次迭代都会运行确定性驱动程序，然后根据其 VERDICT 采取行动。

步骤 1：运行一次测试循环

调用驱动程序（根据上述项目标记自动检测测试命令： package.json 测试脚本、pytest/pyproject.toml、cargo test、go test， 或 Makefile 中的 test: 目标）：

bash "${CLAUDE_SKILL_DIR}/scripts/run-test-cycle.sh" --pattern "$0" --max-cycles 10

将解析出的 test-pattern 替换为 --pattern 的值（若没有则省略），并填入解析出的 --max-cycles 值。读取结构化输出中的 VERDICT= 行以及限定长度的 === TEST OUTPUT === 尾部内容。

步骤 2：根据判定结果分支
VERDICT含义操作
GREEN测试命令以 0 退出——测试套件通过转到步骤 3（重构），然后停止
CONTINUE测试套件失败，且未达到上限进行最小修复（步骤 2a），然后重复步骤 1
STUCK连续 3 个循环出现相同的失败特征——没有进展停止；报告阻碍，并请求输入
CAP_REACHED循环次数达到 --max-cycles停止；报告剩余失败
SETUP_ERROR无法检测或运行测试命令停止；询问如何运行测试，或使用 --test-cmd 重新调用
步骤 2a：进行最小修复（CONTINUE 时）

阅读 === TEST OUTPUT === 尾部内容并找出失败原因：

  1. 哪些测试失败，以及预期结果与实际结果分别是什么。
  2. 根本原因：缺少实现、返回值错误、缺少边界情况，或集成问题。
  3. 对代码进行最小修复——只修复失败测试所需的问题。 不要通过修改测试来让它们通过；这样会把测试套件这个独立裁判变成自我评判的循环（见下文“循环完整性”）。

然后重复步骤 1。驱动程序会递增循环计数器并重新检查。

步骤 3：测试通过时进行重构（GREEN 时）

测试套件通过后，查找可改进之处——重复代码、魔法数字、过长函数、不明确的名称、复杂的条件语句——并在不改变行为的前提下进行重构。每次重构后都重新运行步骤 1，确认测试套件仍然通过。如果没有剩余的改进空间，则报告成功并停止。

步骤 4：报告

总结运行的循环次数、所做的修复、执行的重构，以及最终状态（全部通过／因某原因受阻，并给出建议的下一步）。

循环完整性

这个循环的停止条件就是测试套件本身——一个独立的机械判定器（测试失败时不会在意你有多努力），这正是 .claude/rules/loop-integrity.md 支柱 1 的要求。驱动脚本让判定结果确定无误：GREEN 表示测试套件自身以退出码 0 结束，而不是你的主观判断。--max-cycles 上限（CAP_REACHED）和连续 3 次出现相同失败的规则（STUCK）是防止无限循环的边界。不要通过编辑测试来让测试通过——那会把独立判定器变成自我判定的循环。

常见失败模式

症状修复（最小化）
undefined is not a function、NameError实现缺失的函数/类；只需添加签名和一个虚拟返回值
Expected X but got Y只修正返回值——不要添加额外逻辑
特定输入导致失败添加一个条件来处理该边界情况
组件交互时失败修复集成点，而不是整个组件

自动停止条件

出现以下情况时停止并报告：所有测试均通过，且无需再重构（SUCCESS，GREEN）；STUCK（相同失败连续出现 3 次——驱动脚本发出的无进展信号）；CAP_REACHED（达到 --max-cycles 上限）；SETUP_ERROR（测试命令本身损坏/无法检测）；或修复方案不明确（NEEDS USER INPUT）。

Agent 式优化

上下文命令
单次循环，自动检测bash "${CLAUDE_SKILL_DIR}/scripts/run-test-cycle.sh" --max-cycles 10
聚焦某种模式bash "${CLAUDE_SKILL_DIR}/scripts/run-test-cycle.sh" --pattern "$0"
覆盖测试命令bash "${CLAUDE_SKILL_DIR}/scripts/run-test-cycle.sh" --test-cmd "pytest -x -q"
启动全新循环（重置循环状态）bash "${CLAUDE_SKILL_DIR}/scripts/run-test-cycle.sh" --reset
查看判定结果bash "${CLAUDE_SKILL_DIR}/scripts/run-test-cycle.sh" --max-cycles 10 | grep -E '^VERDICT='

评论

支持 Markdown