用 AI 写测试用例和自动化脚本

这篇适合谁 / 不适合谁

适合：

• 要给已有函数 / 接口补单测、边界用例
• 想用 TDD 但不知道先写哪条测试
• 要给关键用户路径补端到端（E2E）测试

不适合：

• 代码本身逻辑都没定（先定行为再测）
• 要求 AI 替你决定"什么算正确"（正确性由你定义）
• 把测试覆盖率当 KPI 刷量（绿了不等于对了）

开始前准备什么

1. 被测代码：要测的函数 / 模块 / 接口定义。
2. 行为约定：输入输出的边界、异常分支、期望。
3. 测试框架：单测用项目的（Vitest/Jest/pytest），E2E 用 Playwright。

操作步骤

1. 装 skill

tdd-workflow 是测试驱动工作流技能包，复制目录到客户端技能目录（与一般 Agent Skill 装法一致）：

2. 先给行为，再让 AI 写测试

基于下面这个函数，用 Vitest 写测试：
- 覆盖：正常输入、空值、越界、类型错误各一条
- 每条测试只断言一个行为，命名说清预期
- 不要改函数实现，只补测试文件
先列出你觉得最容易翻车的 3 个边界，再写。

3. TDD：先红后绿

想练 TDD，让 AI 先写失败测试（红），你实现到通过（绿），再重构：

用 tdd-workflow：先为"购物车结算"写一条会失败的测试（红），
描述清楚期望行为；等我实现后跑通（绿），再提议一处安全的重构。

4. 补 E2E 关键路径

用户路径用 e2e-testing 写 Playwright 脚本，只覆盖"出错代价最高"的 2-3 条，而不是全点一遍：

用 Playwright 写一条 E2E：从登录到下单成功。
只断言关键状态（下单成功提示、订单号生成），不要逐元素比对。

会踩的坑

FAQ

没有测试框架也能写吗？

能，让 AI 按你项目的框架写；没框架就先定一个再写。

AI 写的测试能直接信吗？

先跑一遍确认真的失败过（红），再实现到绿，避免"假绿"。

TDD 一定要先写测试吗？

推荐。先红后绿能让行为先被定义，实现只为通过测试。

E2E 要覆盖多少？

只覆盖出错代价最高的关键路径，全点一遍又脆又慢。

覆盖率低怎么办？

先补边界和异常分支，比堆正常流用例有用。

相关指南

顺着这些场景接着看：

• 用 AI 写代码、做代码审查和重构
• 让 AI 做一次像样的代码评审

相关源码

• affaan-m/ECC · tdd-workflow 源码
• affaan-m/ECC · e2e-testing 源码
• mattpocock/skills · tdd 源码
• Agent Skill 开放格式规范

一句话结论

结论：测试的价值在"抓住真会出事的路径"——给 AI 真实代码或行为约定，让它补边界用例，别让它凭空造被测对象。