AI 测试为什么总有水分？guard-skills test-guard 九条铁律，完整拦截 mock 滥用与测试膨胀-开发者社区

【免费下载链接】guard-skills

Guard skills for coding agents, quality gates that catch AI-generated failure modes in code, tests, and docs

项目地址：https://gitcode.com/gh_mirrors/gu/guard-skills

让 AI Agent 写测试，拿到一个"全绿"的文件，越看越心惊：MagicMock()满天飞、测试体近乎复制粘贴、断言的其实是框架而不是自己的代码——这就是AI 测试最常见的"注水"问题。开源项目 guard-skills 就是为此而生：它是面向 coding agents 的质量门禁（quality gates），其中的 test-guard 专管测试代码，在 AI 写完测试后逐条复审，在提交或合并前完整拦截 mock 滥用与测试膨胀。

为什么 AI 生成的测试容易"注水"

SKILL.md 开宗明义：coding agents 会过度生成测试。三种典型症状，每一条"看起来很有产出"，代价却要在维护期连本带利地还：

注水症状	表面看	实际代价
mock 堆满的单元测试，断言实现细节	覆盖率很漂亮	每次重构都碎，且抓不到真 bug
近乎重复的测试体，只差一个值	用例列表很长	改一处要改 N 处
重新验证框架本身的行为	全部通过	零价值，纯浪费

最快接入方法：一行命令装上 test-guard

test-guard 是反应式评审门禁：先让 Agent 写测试，再在展示、提交或合并前跑一遍复审。安装只需一行：

npx skills add amElnagdy/guard-skills --skill test-guard

使用也很直接，对 Agent 说一句话即可：

Use $test-guard on the tests you just wrote.

它覆盖 pytest、PHPUnit/Pest、Jest/Vitest、Go 测试、WordPress/WooCommerce 测试等。仓库共 5 个 guard，分工见 README.md 的选择表。

九条铁律逐条拆解

SKILL.md 的九条铁律可以按三组来记：别测错地方（1、2、7、8）、别写多余（3、4、5、9）、别删重要的（6）。

规则 1：测行为，不测实现

只断言调用方视角能看到的返回值和副作用。断言"内部函数被以某参数调用过"的测试，每次重构都会碎，却抓不到一个 bug。

规则 2：每个 mock 都必须有正当理由

这是拦截 mock 滥用最核心的一条。mock 只允许出现在系统边界：网络/HTTP、LLM API、数据库、外部文件 IO、时钟与随机数、第三方 SDK。内部类与辅助函数一律不许 mock——为了隔离"单元"而人为撕开的缝，恰好藏住了最值得抓的集成 bug。

规则 3：一个场景一个测试，变体用数据驱动

两个以上测试 setup 相同、只差输入输出值，就合并成一个数据驱动测试：pytest 的@pytest.mark.parametrize、PHPUnit 的#[DataProvider]、Jest 的test.each。正反对比示例见 references/pytest.md。

规则 4：每个测试都要能"自证存在"

问一句："它能抓住哪个其他测试都抓不到的 bug？"答不上来就别写。典型该删的：构造函数赋值、常量等于字面量、日志消息的字符串格式。

规则 5：用场景命名，而不是复读函数签名

命名格式test_<场景>_<预期结果>，名字读起来应像一条需求：

反例	正例
`test_parse_response_missing_field`	`test_malformed_response_falls_back_to_default`
`test_add_tags_single_string`	`test_single_tag_normalizes_to_list`

规则 6：生产回归测试神圣不可侵犯

复现真实线上 bug 的测试永远成立，豁免规则 4，且永不删除；建议在名字里写上事故日期或 issue 号。

规则 7：别给框架保证写测试

不用测"验证库确实会验证、ORM 确实会提交"。自检标准很干脆：删掉项目里全部自定义代码后仍会通过的测试，就该删。

规则 8：状态对象必须是真的，永不 mock

数据模型、DTO、实体、状态对象一律构造真实实例。MagicMock()冒充 Pydantic 模型，恰恰会隐藏字段拼写错误和校验失败——这正是最值得抓的 bug。

规则 9：被测的是基础设施，就用真基础设施

当数据库查询、持久化逻辑本身是测试对象时，用真实测试数据库跑真实迁移；此时 mock 掉 session "等于什么都没测"。数据库只是行为副作用时，mock 则没问题。

严重等级：哪些必须改，哪些可以商量

test-guard 的定位是"犀利的评审者，而不是迂腐的学究"（SKILL.md），它对九条规则分级（严重等级指南）：

等级	规则	含义
🔴 必须修复	1、2、8	藏真 bug 或让测试脆弱，合并前必须改
🟡 应当修复	3、4、5、7	造成测试膨胀与维护拖累，强烈建议改
💎 神圣	6	永不删除，无条件放行
🔵 值得记录	9	测试架构问题，指出但不因此阻塞小改动

评审输出采用固定格式（报告格式）：Rule N 违反 + 一句话问题 + 一句话修复，按文件分组，无问题的文件不提。

进阶：按技术栈渐进加载框架参考

test-guard 不把框架细节塞进主文件，而是渐进式披露（References 章节）——Agent 只在你用到对应技术栈时才加载相应参考：

Python / pytest → references/pytest.md：parametrize、fixture、真实 Pydantic 实例
PHP / PHPUnit / Pest / WordPress → references/phpunit.md：WordPress 工厂对象、WooCommerce helper
JavaScript / TypeScript / Jest / Vitest → references/jest.md：test.each、msw、快照纪律
LLM 应用 → references/llm-app-testing.md：额外三条规则

如果你的项目调用 LLM API、搭 Agent 框架或接入可观测性，还会额外追加三条：提示词测契约不测措辞（规则 10）、可观测性是基础设施不做单元测试（规则 11）、Agent 流程只测状态迁移（规则 12）。

最快落地四步走

安装：npx skills add amElnagdy/guard-skills --skill test-guard（可用--agent指定目标 Agent）
写完后复审：一句 "Use $test-guard on the tests you just wrote"
按报告修改：先改"必须修复"项，逐条按 Fix 建议处理
项目规则优先：test-guard 会先读取项目自身的 Agent 说明与测试文档（CLAUDE.md / AGENTS.md），与项目约定冲突时以项目为准

小提醒：skills 是以副本安装的，新版本发布后需运行npx skills update刷新。

总结

AI 测试"注水"，不是 AI 偷懒，而是"多写"和"写好"是两个不同的奖励信号。guard-skills 的 test-guard 把"写好"变成了一道可执行的关卡：在系统边界拦截 mock 滥用、用数据驱动合并测试膨胀、为生产回归测试上锁。再配合管生产代码的 clean-code-guard 和管文档的 docs-guard，AI Agent 的产出就能从"能跑"走向"敢合并"。