企业官网建设流程全解析

no-mistakes e2e测试体系：recorded fixtures与fakeagent命令

【免费下载链接】no-mistakesgit push no-mistakes项目地址: https://gitcode.com/GitHub_Trending/no/no-mistakes

no-mistakes 是一个"git push 即质检"的守护流水线工具：把分支推送到名为no-mistakes的远端后，守护进程会自动驱动 rebase、lint、test、review、CI 等步骤，并调用 Claude、Codex、Grok、OpenCode、Antigravity 等 AI 代理完成代码审查与修复。为了让这套流水线本身可以被可靠地验证，项目内置了一套 e2e（端到端）测试体系——用 fakeagent 命令 模拟真实 AI 代理，用 recordfixture 录制的recorded fixtures（录制固件）回放真实协议报文，让测试既离线、确定，又能真实校验线格式。

一、e2e 测试体系解决什么问题

如果只用单元测试来验证流水线编排，信号其实很弱：真正的风险藏在"真实 git 仓库 + 真实守护进程 + 真实代理 CLI 交互"这条完整路径里。no-mistakes 的 e2e 测试直接运行编译出来的真实二进制，对临时 git 仓库执行一次完整的"用户推送分支 → 流水线跑完"旅程（见 internal/e2e/doc.go）。

但直接跑测试会撞上两堵墙：

1. 要烧真金白银的 API 配额——每次调用 Claude/Codex 都是真实请求；
2. 结果不确定——AI 的回复每次都不一样，断言无法稳定通过。

项目的答案是"录制 + 回放"：开发时用recordfixture命令手工录制一次真实代理的输出；测试时用fakeagent命令回放录制好的 recorded fixtures，并记录每一次调用供断言。

二、fakeagent 命令：一个二进制冒充所有 AI 代理

fakeagent 是真实 Claude、Codex、Grok、OpenCode、Antigravity CLI 的确定性替身（cmd/fakeagent/main.go）。它的巧妙之处在于：

• 一个二进制，多副身份：e2e 的测试脚手架 harness.go 把同一个 fakeagent 可执行文件软链接成claude、codex、grok、opencode、antigravity（外加探测名agy）等多个名字，并置于 PATH 最前。fakeagent 启动时读取argv[0]的文件名，决定"自己是谁"、该说哪种线协议。
• 顺手堵住真实远端：gh和tea也被链接成 fakeagent 的桩（stub）。e2e 中任何"走错路的" GitHub/Gitea 调用都只会打到桩上——gh auth status直接报未认证（失败即安全），绝不可能意外创建真实 PR。
• 全程留痕：每一次调用都会以 JSONL 追加写入$FAKEAGENT_LOG（时间、代理、参数、完整 prompt），测试可以精确断言"流水线到底给代理发了哪些提示词"。

用 Scenario YAML 驱动假代理行为

fakeagent 的行为由$FAKEAGENT_SCENARIO指向的 YAML 文件决定（scenario.go）。每条规则是"prompt 子串匹配 → 预置回复"，并且可以在回复前真正修改工作区文件——这就是"修复轮"能实际改动文件的方式：

actions: - match: "review the diff" text: "found a bug" structured: findings: [{message: "nil dereference"}] risk_level: high - match: "" # 兜底规则：全部干净 text: "no issues found"

不设置 Scenario 时，fakeagent 返回内置的"一切干净"回复，满足 no-mistakes 要求的所有 JSON Schema（空 findings、低风险等级等）。

三、recordfixture 命令：录制真实响应

recorded fixtures 不是手写出来的，而是真枪实弹录下来的。cmd/recordfixture 是一条手工操作、不进 CI 的录制命令（注释里写得直白："每次录制都会烧掉真实 API 配额"）：

go run ./cmd/recordfixture claude --out internal/e2e/fixtures/claude go run ./cmd/recordfixture codex --out internal/e2e/fixtures/codex go run ./cmd/recordfixture opencode --out internal/e2e/fixtures/opencode

录制器自己不持有任何 Schema 知识——它只是调用真实 CLI，把线协议输出原样落盘，每个代理录制"结构化输出"和"纯文本"两种风味（以 claude 为例，见 claude.go）。录完后还有一个关键收尾动作：脱敏（scrub.go）——把录制者本机的 home 目录、临时目录、会话 UUID 等隐私信息替换成占位符，保证可以安全地提交到公共仓库。

最终的 fixtures 目录结构一目了然（internal/e2e/fixtures）：

例如可以翻看 claude/structured.jsonl 里真实录制下来的流式 JSON 报文。

四、回放机制：让 e2e 成为真正的线格式回归检测

回放逻辑在 fixture.go：当FAKEAGENT_FIXTURE指向固件根目录时，fakeagent 优先从<代理>/<风味>/下读取录制文件逐条回放真实的线协议报文，仅在 Scenario 需要时修补个别响应字段；读不到才回退到合成响应。

测试脚手架在 NewHarness 中默认就设置好了FAKEAGENT_FIXTURE，源码注释点明了这个设计的价值：

"This is what makes the e2e a real wire-format check."（这才是 e2e 成为真正线格式检查的关键）

它的意义在于：如果上游代理的线格式发生了漂移，重新录制一次就能产出新固件，fakeagent 的回放自动跟上——不需要手工维护任何"格式模拟器"。测试既稳定（离线、确定），又不失真（报文来自真实 CLI）。

五、如何运行 e2e 测试

e2e 测试全部藏在e2e构建标签后面，日常go test ./...不会跑到它们，只能通过专用入口触发（scripts/e2e.sh）：

make e2e # 等价于 scripts/e2e.sh # 即 go test -tags=e2e -count=1 -timeout 480s ./internal/e2e/... ./internal/pipeline/steps/...

每个测试用例由一套独立的 Harness 装配：临时文件系统（裸 origin 仓库 + 工作克隆）、独立$NM_HOME、代理软链接目录、调用日志文件。更贴心的是，守护进程也有"临时所有权"机制（internal/e2edaemon）：每个用例申领一个并发槽位并把 daemon PID 登记进清单，e2e.sh在退出时兜底清扫残留守护进程——即使测试进程被 SIGKILL，下次跑套件时也会自动回收遗留 daemon，不会污染你本机的真实服务。

六、关键文件速查

总结

no-mistakes 的 e2e 测试体系用录制与回放优雅地解决了 AI 流水线测试的两大难题：recordfixture在开发机上真实烧一次配额，把各代理的线协议报文录成 recorded fixtures 并脱敏入库；fakeagent则以一个二进制多链接的方式冒充所有 AI 代理（乃至gh/teaCLI），离线、确定、且全程留痕地回放这些报文。配合 Harness 的临时仓库与守护进程清单回收，make e2e一条命令就能在干净环境里复现"用户推送 → 流水线全程跑完"的真实旅程——这对任何需要与真实 AI CLI 打交道的开源项目，都是一套值得借鉴的确定性测试范本。

【免费下载链接】no-mistakesgit push no-mistakes项目地址: https://gitcode.com/GitHub_Trending/no/no-mistakes