tdd-workflow

Estrelas17

Forks1

Atualizado17 de julho de 2026 às 23:46

在 mbun 项目中开发任何功能或修复缺陷时使用。规定以 bun/node 原生测试集为验收标准的 TDD 开发循环、checkpoint 提交约定与记录流程。

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Fonte

Sunrisepeak

Sunrisepeak/mbun

Abrir repositório GitHub Ver repositórios do creator

Download

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de garantia de qualidade de software e testadoresInformática e Matemática·SOC 15-1253

SKILL.md

readonly

name	tdd-workflow
description	在 mbun 项目中开发任何功能或修复缺陷时使用。规定以 bun/node 原生测试集为验收标准的 TDD 开发循环、checkpoint 提交约定与记录流程。

mbun TDD 开发流程

mbun 的核心开发约束：bun / node 原生测试集是唯一验收标准，不得为通过测试而修改/弱化原测试语义（compat/ 下的上游语料是只读输入；可以做移植性适配，如路径、运行器桥接，但断言语义必须保持）。

开发循环（red → green → refactor）

确定验收目标：找到任务对应的上游测试文件（compat/bun/test/ / compat/node/test/parallel/），或为纯逻辑模块圈定行为规范（如从 bun 参考源 compat/bun/src/ 对照移植）。
建立测试目标（red）：
- 纯逻辑模块：落地为 modules/<member>/tests/test_<模块>.cpp（成员目录内 mcpp test 自动发现），引擎级断言可直接翻译上游测试的期望值（参照 modules/html_rewriter/tests/）。
- 运行时行为：直接以 mbun test compat/bun/test/<file> 的 pass/fail 为红绿信号（跑法与沙箱见 mbun-runtime-debugging skill）。
- 确认新测试失败——失败原因必须是「功能未实现」，而非编译/环境错误。
实现（green）：按模块实现，遵循 .agents/skills/mcpp-style-ref/SKILL.md 编码规范（新功能优先独立 workspace 成员 + .cppm 模块），只写让测试通过所需的代码。
重构（refactor）：测试保持通过的前提下消除重复、理顺模块边界。
回归验证：改动波及的既有套件必须与基线对照（同文件改动前后 pass/fail 数一致或更好）；跑测一律经 tools/integration/ 的资源受限沙箱，防 fork/泄漏冻机。
checkpoint 提交：
```
<type>(<scope>): <subject>
```
- type: feat / fix / test / refactor / docs / chore / research
- 一个开发项至少一个 commit；红绿分离提交更佳（test(scope): ... 先行，feat(scope): ... 随后）。
记录：实质进展写入 changelog.md（带测试数据：套件 x/y → x'/y'，0 回归声明要有对照证据）；全量语料测量结果固化到 compat/data/（复现方法见 compat/README.md）；README「兼容性数据」表只放真实测得的数字。

禁止事项

❌ 修改 compat/ 下上游测试的断言或删除测试用例来「让测试通过」
❌ 未真实跑过验收测试就声称任务完成（构建通过 ≠ 功能完成）
❌ 跳过 red 阶段直接写实现（无法证明测试有效）
❌ 一次 commit 混杂多个不相关开发项
❌ 裸跑可能 spawn/hang 的测试（必须经 safe-test.sh / bounded_run 沙箱）

Mais deste repositório

mesmo repositório

dev-process

Sunrisepeak/mbun

在本仓开发任何改动前用。规定 issue 先行的开发流程,按 bugfix / 优化 / 新功能分流;新功能须经 issue 充分讨论并在 .agents/docs 落地设计方案;衔接 tdd-workflow 与本体验证 / 测试 / CI / PR 规范。开发前先读本 skill。

2026-07-3117

mcpp-style-ref

Sunrisepeak/mbun

为 mcpp 项目应用 Modern/Module C++ (C++23) 编码风格。适用于编写或审查带模块的 C++ 代码、命名标识符、组织 .cppm/.cpp 文件，或用户提及 mcpp、module C++、现代 C++ 风格时。

2026-07-3117

issue-reporting

Sunrisepeak/mbun

向本仓提交 issue / 发起讨论时用。规定一份好问题反馈的 SOP——软件/版本、报错信息、初步分析、相关资料,并去除本地隐私(用户名/token 等替换)。凡要创建 issue、反馈 bug、发起讨论,先读本 skill 再动手。

2026-07-1817

mbun-runtime-debugging

Sunrisepeak/mbun

调试 mbun 运行时测试失败/崩溃时用。提供仓库实测可用的定位配方——选二进制、单文件跑测、gdb 抓 backtrace、按 API 定位源码、常见坑排查清单、何时跳过。凡处理 bun 测试跑不过/段错误/hang/断言失败，先读本 skill 再动手，避免每个 task 重复摸索拖慢。

2026-07-1717

mbun TDD 开发流程

开发循环（red → green → refactor）

确定验收目标：找到任务对应的上游测试文件（compat/bun/test/ / compat/node/test/parallel/），或为纯逻辑模块圈定行为规范（如从 bun 参考源 compat/bun/src/ 对照移植）。

建立测试目标（red）：

纯逻辑模块：落地为 modules/<member>/tests/test_<模块>.cpp（成员目录内 mcpp test 自动发现），引擎级断言可直接翻译上游测试的期望值（参照 modules/html_rewriter/tests/）。
运行时行为：直接以 mbun test compat/bun/test/<file> 的 pass/fail 为红绿信号（跑法与沙箱见 mbun-runtime-debugging skill）。
确认新测试失败——失败原因必须是「功能未实现」，而非编译/环境错误。

实现（green）：按模块实现，遵循 .agents/skills/mcpp-style-ref/SKILL.md 编码规范（新功能优先独立 workspace 成员 + .cppm 模块），只写让测试通过所需的代码。

重构（refactor）：测试保持通过的前提下消除重复、理顺模块边界。

回归验证：改动波及的既有套件必须与基线对照（同文件改动前后 pass/fail 数一致或更好）；跑测一律经 tools/integration/ 的资源受限沙箱，防 fork/泄漏冻机。

checkpoint 提交：

<type>(<scope>): <subject>

type: feat / fix / test / refactor / docs / chore / research
一个开发项至少一个 commit；红绿分离提交更佳（test(scope): ... 先行，feat(scope): ... 随后）。

记录：实质进展写入 changelog.md（带测试数据：套件 x/y → x'/y'，0 回归声明要有对照证据）；全量语料测量结果固化到 compat/data/（复现方法见 compat/README.md）；README「兼容性数据」表只放真实测得的数字。

禁止事项

❌ 修改 compat/ 下上游测试的断言或删除测试用例来「让测试通过」

❌ 未真实跑过验收测试就声称任务完成（构建通过 ≠ 功能完成）

❌ 跳过 red 阶段直接写实现（无法证明测试有效）

❌ 一次 commit 混杂多个不相关开发项

❌ 裸跑可能 spawn/hang 的测试（必须经 safe-test.sh / bounded_run 沙箱）