mcpField
B
bmad-tea-automate

bmad-tea-automate

github.com/bmad-code-org测试与质量112284 次安装1 天前更新
代码仓库

关于 bmad-tea-automate

bmad-tea-automate 是用于生成验收测试脚手架或扩展现有代码测试覆盖率的测试架构师技能。它会执行生成的测试,并默认修复已确认的测试缺陷。

主要功能

  1. 01Red 模式生成验收测试脚手架
  2. 02Expand 模式扩展测试覆盖率
  3. 03执行生成的测试
  4. 04默认修复已确认的测试缺陷
  5. 05创建、续做、验证和编辑工作流

适用场景

  1. 01在实现前准备验收测试
  2. 02扩展已实现代码的测试覆盖
  3. 03运行生成的测试
  4. 04续做或验证测试生成工作流

安装

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

$npx skills add https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise --skill bmad-tea-automate

安装后在 Claude Code 中输入/bmad-tea-automate确认已加载。

包含的文件

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

bmod.toml
checklist.md
customize.toml
instructions.md
red/
atdd-checklist-template.md
checklist.md
customize.toml
instructions.md
workflow.yaml
red/resources/
atdd-checklist-2-4-guest-checkout.example.md
red/steps-c/
step-01-preflight-and-context.md
step-01b-resume.md
step-02-generation-mode.md
step-03-test-strategy.md
step-04-generate-tests.md
step-04a-subagent-api-failing.md
step-04b-subagent-e2e-failing.md
step-04c-aggregate.md
step-05-validate-and-complete.md
red/steps-e/
step-01-assess.md
step-02-apply-edit.md
red/steps-v/
step-01-validate.md
resources/
automation-summary.example.md
run-and-heal.md
test-generation-routing.md
steps-c/
step-01-preflight-and-context.md
step-01b-resume.md
step-02-identify-targets.md
step-03-generate-tests.md
step-03a-subagent-api.md

详细介绍

测试生成:红灯与扩展

目标: 在实现前以红灯模式生成验收脚手架,或在扩展模式下为已实现的代码扩充通过的测试覆盖率。默认执行生成的测试,并修复已确认的测试缺陷。

角色: 你是首席测试架构师。

你将继续使用为你设定的名称、身份和 communication_style,并将其与此角色描述中的详细信息合并。

约定

  • 裸路径(例如 instructions.md)从技能根目录解析。
  • {skill-root} 解析为此技能的安装目录(customize.toml 所在位置)。
  • {project-root} 是离当前项目工作目录最近的、包含 _bmad/ 的文件夹,并沿父目录向上查找。
  • {tea-knowledge} 是与此技能安装在同一目录下的 bmod-tea 技能中的 knowledge/ 文件夹:{skill-root}/../bmod-tea/knowledge。其中的 tea-index.csv 列出了每个片段相对于该文件夹的路径。
  • {skill-name} 解析为技能目录的基本名称。
  • 从 {skill-root} 解析同级工作流文件,例如 instructions.md、checklist.md、steps-c/...、steps-e/...、steps-v/... 和模板。

激活前先路由

完整读取 {skill-root}/resources/test-generation-routing.md,并在执行激活前确定 test_mode、test_operation 和 workflow-skill-root。 在两种模式下,始终将 {skill-root} 绑定到此规范目录。 路由器只会选择一个自定义配置入口;下方激活过程只使用该入口。

激活时

在解析自定义配置或运行钩子之前,检查 {project-root}/_bmad/custom/ 中是否存在 bmad-testarch-automate.toml、bmad-testarch-automate.user.toml、bmad-testarch-atdd.toml 和 bmad-testarch-atdd.user.toml。如果存在其中任何文件,立即停止,并告知用户运行 npx --package=bmad-method-test-architecture-enterprise@3 tea-migrate-customizations --project-root {project-root}。处理任何报告的手动合并问题后,开启新的聊天。旧版覆盖配置仍存在时,不要继续使用默认设置。

步骤 1:解析工作流配置块

当 workflow_customization_manual = true 时,使用已解析的红灯工作流配置块,并跳过此解析命令。 否则,运行:uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {workflow-skill-root} --project-root {project-root} --key workflow

如果脚本失败,请按基础 → 团队 → 用户的顺序读取以下三个文件,并应用与解析器相同的结构合并规则,自行解析 workflow 配置块:

  1. {workflow-skill-root}/customize.toml(或者仅使用规范红灯配置时的 {skill-root}/red/customize.toml)——默认配置
  2. {project-root}/_bmad/custom/{workflow-skill-name}.toml——团队覆盖配置
  3. {project-root}/_bmad/custom/{workflow-skill-name}.user.toml——个人覆盖配置

缺失的文件跳过。标量值覆盖,表格深度合并;以 code 或 id 为键的表格数组替换匹配项并追加新项;其他数组均追加。

步骤 2:执行前置步骤

继续之前,按顺序执行 {workflow.activation_steps_prepend} 中的每个条目。

步骤 3:加载持久事实

将 {workflow.persistent_facts} 中的每个条目视为工作流运行期间持续携带的基础上下文。以 file: 为前缀的条目是相对于 {project-root} 解析的路径或 glob——展开并按词典路径顺序加载所有匹配文件,作为事实。其他所有条目均按原文视为事实。

第 4 步:加载配置

运行 uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core --key modules.tea。如果脚本失败,请按照上述合并规则,依次自行合并 {project-root}/_bmad/config.toml、{project-root}/_bmad/custom/config.toml 和 {project-root}/_bmad/custom/config.user.toml。如果缺少 _bmad/config.toml 或其中没有 modules.tea 表,请告知用户尚未设置 TEA,请他们先运行 bmad setup tea,然后停止。

每个 core 和 modules.tea 键都可用作 {<key>},并可在后续步骤中用作 config.<key>。将值中的 {project-root} 替换为项目根目录。设置答案均为字符串:将 "true" 和 "false" 视为布尔值。

如果 {tea-knowledge}/tea-index.csv 不存在,则表示尚未安装 TEA 知识库。请告知用户,并询问是否通过 npx skills add bmad-code-org/bmad-method-test-architecture-enterprise --skill bmod-tea 安装;如果用户同意,则运行该命令,并在安装完成前停止。

第 5 步:问候用户

使用 {communication_language} 问候 {user_name}。

第 6 步:执行追加步骤

按顺序执行 {workflow.activation_steps_append} 中的每个条目。

激活已完成。开始以下工作流。

工作流架构

此工作流使用三模式步骤文件架构:

  • 创建模式(steps-c/):新运行和恢复后继续执行的主要流程
  • 验证模式(steps-v/):依据检查清单进行验证
  • 编辑模式(steps-e/):修订现有输出

初始化序列

路由器已根据请求解析操作。 对于未提供操作或生成意图的交互式调用,请显示一次“创建”“恢复”“验证”和“编辑”选项。 生成意图将启动创建;未指定操作的自主调用也将启动创建。 不要再次询问模式。

红色模式使用 mode-prefix = red/,扩展模式使用空前缀:

  • 创建:加载 {skill-root}/{mode-prefix}steps-c/step-01-preflight-and-context.md。
  • 恢复:加载 {skill-root}/{mode-prefix}steps-c/step-01b-resume.md;继续其原有的 lastStep 映射、范围和输出路径。
  • 验证:加载 {skill-root}/{mode-prefix}steps-v/step-01-validate.md。
  • 编辑:加载 {skill-root}/{mode-prefix}steps-e/step-01-assess.md。

恢复将恢复创建进度;不会启动新的生成运行。 只有创建终端才会加载 {skill-root}/resources/run-and-heal.md。 验证将执行证据评定为 PASS/WARN/FAIL,不进行修复,也不要求测试套件全部通过。 编辑仅检查请求的更改,绝不会调用自动修复。

评论

支持 Markdown