改了一行，不知道会崩哪儿。这种恐惧，能治。

上上篇讲重构时，我留了样东西叫「行为快照表」——改代码前先把”这段功能现在的表现”手工记一遍：输入什么、出来什么。改完照表跑，对上就安全。

那张表好用，但致命缺点是它是手工的。三个功能点跑一遍五分钟，三十个功能点跑一小时，于是你就不跑了。不跑等于没安全网。

这一篇就一句话：把那张手工快照表，变成一行命令就能全跑完的代码。 这东西叫单元测试。

一、先说人话：单元测试到底是个啥

别被”测试”吓到，它跟”测试工程师”两码事。最土的比喻：

手工验证，是把整台机器开起来看它转不转。 单元测试，是把每个零件单独拿出来，通上电，看它响不响。

“单元”就是一个函数、一个方法、一小块独立逻辑。你写一小段代码专门调用它，检查”我给它 3 和 5，它是不是返回 8？”是就打勾，不是就报红。

一个最小的单元测试，本质只有三句话：

1. 准备：输入是什么
2. 执行：调用它
3. 断言：结果应该等于什么

第三步”断言”是灵魂——你写死在代码里那句“它必须等于这个”。以后谁改代码，结果不等于这个，机器当场报警。这就是它比手工表强的地方：机器帮你看、帮你对，一秒能对完几百条。

二、该测什么？记住「四靶」：正、边、错、空

小白写测试最大问题不是不会写，是不知道该测哪些情况。写完一个就觉得”测过了”，结果线上还炸，因为你只测了最顺的那种。

归成四个靶子，口诀：正、边、错、空。

靶一：正（正常情况） 最典型最顺的那一种，用户按你想的那样用。算折扣原价 100 打 8 折 → 80；手机号 13812345678 → 通过。这一靶最容易想到，也最没价值，只能证明”能用”不能证明”可靠”。

靶二：边（边界值） 刚好卡在临界线上的数，线上事故八成出在这。 满 100 减 20，那正好 100 呢？库存”大于 0 才能买”，正好 0、负数呢？分页每页 10 条，正好 10/11/第一页/最后一页呢？→ 记一条：代码里出现「大于」「小于」「至少」「最多」，那个数字本身就是必测靶。

靶三：错（错误输入） 用户会乱输，接口会返垃圾，必然的。手机号栏输汉字、金额栏输负数、日期输”2026-13-45”。你要测的不是”它能不能处理”，而是”出错时是不是优雅报错，而不是整个崩掉”。

靶四：空（空值） 新手漏得最多，也是线上崩溃第一元凶。 空字符串 ""、空数组 []（列表一条数据没有，页面白屏？）、null/None（数据库那字段本来就是空）、用户没填/接口没返。很多”莫名其妙崩溃”追到底，就是某处是空的，代码默认它一定有值。

四靶速记表：

务实标准：一个函数，四靶各写一条，四条就够用。 别一上来想写二十条。

三、让 AI 写测试：四步法「框、说、生、补」

流程压成四步，口诀：框、说、生、补。

第一步：框——先定测试框架

新手第一个坑。 直接说”帮我写单元测试”，AI 随便挑个框架给你写，复制过去一跑满屏报错——你项目根本没装那个框架。正确做法：先问 AI 你该用什么。 把项目依赖清单文件（记录”用了哪些工具”的文件）整份贴给 AI，问清三件事：① 已装测试框架吗、装哪个？② 没装推荐哪个、安装命令？③ 测试文件放哪、文件名怎么起。问清这三件少走一半弯路。

第二步：说——说清”它应该做什么”，别让 AI 猜

全篇最重要的一句话：千万不要只把代码丢给 AI 说”帮我写测试”。

因为 AI 会照着你的代码写测试。代码有 bug，AI 就把 bug 当”正确答案”写进断言。比如”满 100 减 20”你写错了写成”大于 100 才减”，AI 一看写出测试：”输入 100 应该不减。”测试绿了，可 bug 被永久固化，还有测试给它背书。

破法：先用大白话描述函数「应该」做什么，让 AI 按描述写，不是按代码写。 对比：

• ❌ 差：「这是我的代码，帮我写测试。」
• ✅ 好：「业务规则：订单原价满 100（含 100）减 20，不满不减，负数直接报错。请按这规则写测试。写完后对照我贴的代码，告诉我代码和规则有没有对不上。」

后半句是白送的 bug 检测器，让 AI 拿”规则”和”代码”对一遍，常能当场抓问题。

第三步：生——生成，然后一定要跑起来

AI 给测试代码后，别看，直接跑。 新手常卡在这三类报错：① 找不到文件（引入被测代码的路径不对）② 框架没装（命令不认识）③ 配置缺失（需要配置文件）。这三类全不用自己解决——把报错原文（整段别转述）贴回给 AI，加一句：”我按你给的代码跑，报了这个错，这是完整报错，请告诉我原因和具体改哪个文件哪行。” 这是第 71 篇老规矩：报错贴原文。

跑起来看到第一排绿勾，你才算真入门。

第四步：补——看覆盖率，找洞，补测

跑通后让 AI 教你开覆盖率报告：绿色行 = 被测到过，红色行 = 一次没跑到。

四、覆盖率：别追高，要找洞

覆盖率是新手最容易被骗的数字。 先把话说死：覆盖率高 ≠ 代码没问题。 它只统计”这行被跑过”，完全不管你有没有检查结果对不对。 极端例子：写个测试把所有函数调一遍，一个断言不写，覆盖率 100%，但啥也没测——从不检查结果，返回什么都说通过。

正确用法：不是追高，是找洞。 打开报告只看红色，对每块红的问自己：”这段代码从来没被测过，我慌不慌？”慌（支付金额、权限、扣库存）→ 立刻补；不慌（打印日志、界面颜色）→ 放着。这才是覆盖率真正的用法：一张藏宝图，标出你没走过的路，挑重要的走。

为凑数字写假测试，是纯粹自我欺骗。 数字好看了，安全网还是破的。

五、AI 写测试的三个坑，提前告诉你

坑一：AI 把 bug 当正确答案。 上面说过，破法就是先说规则再让它写，最重要的一条。

坑二：AI 爱写”测了个寂寞”的测试。 它把所有外部依赖都换成假的（术语 mock），假到最后测的全是自己造的假数据，真实逻辑一行没跑到。破法加一句约束：“尽量少用 mock，只有网络请求、数据库、文件读写、当前时间这四类才允许替换成假的，其余用真实调用。”

坑三：AI 造的测试数据太”干净”。 它特爱用”张三”“test@test.com”“123”，全是标准格式一个坑踩不到。破法点名要脏数据：“测试数据要贴近真实：含中文、空格、超长字符串、特殊符号、emoji、前后带空格的输入。”

六、一条铁律：测试红了，先怀疑代码

这条单独说，因为它决定这套东西有没有用。你常会遇到：改了点代码一跑，红了。新手第一反应：”这个测试挡我路了，我把它改改让它过。”打住。

测试红了，永远先怀疑代码，最后才怀疑测试。

测试红是好事，说明安全网起作用了，刚拦下你没意识到的行为变更。把断言改成新结果，等于看到火警响了把警报器电池抠掉。

正确顺序：① 看它红在哪（期望值 vs 实际值）② 问：这变化是我故意的吗？③ 不是故意 → 恭喜抓到 bug，改代码 ④ 是故意（需求真改了）→ 才改测试，并在提交说明写清为什么改。这一条记住了，这篇文章就没白读。

七、完整走一遍：从零到绿灯

1. 贴依赖清单，问 AI 用什么框架、装什么、文件放哪
2. 装好框架，让 AI 写个”1+1=2”级最简单测试，先确保能跑起来（省掉后面 80% 抓狂）
3. 挑最核心的函数（管钱、管权限那个）
4. 用大白话写它应该做什么（业务规则）
5. 让 AI 按规则 + 四靶写测试
6. 跑，报错就贴原文回问
7. 绿了看覆盖率，挑红色重要的补
8. 以后每次改代码，先跑一遍测试

第 8 条才是全部价值所在。 前七步一次性投入，第八步是你此后每天的收益。

提示词模板盒子

模板 1：按业务规则写测试（核心，最重要）

请帮我为下面这个函数写单元测试。

【第一部分：这个函数应该做什么（业务规则）】
用大白话一条条列：
1. ……
2. ……
3. 出现 XX 情况时，应该报错，不能返回错误结果

【第二部分：当前代码实现】
（完整贴代码，不要贴片段）

【第三部分：要求】
1. 测试框架用：XXX
2. 严格按【业务规则】写测试，不要照代码现有行为写
3. 每个规则至少覆盖四类：正（典型正常）/ 边（临界值0、1、正好、最大、最小）/ 错（类型错、格式错、负数）/ 空（空串、空数组、null、字段缺失）
4. 尽量少用 mock，只有网络/数据库/文件/当前时间才允许替换成假
5. 测试数据要贴近真实：含中文、空格、超长串、特殊符号、前后带空格
6. 每条测试上用中文注释写清"测什么、为什么测"
7. 给完整可运行测试文件，不要片段

【第四部分：额外任务】
写完对照【业务规则】和【代码】，告诉我代码有没有和规则对不上，逐条列：规则说啥/代码做啥/造成啥后果。

模板 2：环境搭建与排错（定框架 + 跑不起来用）

【A. 确定框架（第一步必用）】
我是编程新手，想加单元测试，不知从哪开始。下面是我项目依赖清单文件内容：
【把依赖清单完整内容贴这里】
请大白话告诉我四件事：1. 已装测试框架吗、装哪个 2. 没装推荐哪个（新手易上手）、完整安装命令 3. 测试文件放哪、文件名怎么起 4. 装完用什么命令跑。
最后给个最简单"能跑通就行"的示例测试文件（比如测加法函数），我先确认环境通再写真的。

【B. 测试跑不起来（排错专用）】
我按你给的测试代码运行，报错了。
【我执行的命令】（原样贴）
【完整报错信息】（一个字没改全贴）
【我的项目目录结构】（测试文件和被测代码分别在哪）
请告诉我：1. 报错原因（大白话）2. 具体改哪个文件哪行、改成什么 3. 一次只给一处修改，我改完跑一遍再回来。

模板 3：找洞与验伪（覆盖率 + 测试红了用）

【A. 看覆盖率报告找洞】
我跑出覆盖率报告，下面是没被测到的代码行：
【未覆盖代码】（贴报告标红那段）
请做三件事：1. 逐段说明这段代码干啥、啥情况被执行到 2. 按"出事后果严重程度"排成【必须补】【建议补】【可以不管】三档（涉及金额/权限/删除/库存一律必须补）3. 对【必须补】直接给可运行测试代码。
我不追求数字好看，只想补真危险的地方，别为凑数建议给日志/常量/赋值写测试。

【B. 测试失败了，帮我判断】
我改了代码，一条测试红了。请判断该改代码还是改测试。
【失败的测试】（贴）【报错内容】（期望值和实际值那部分必贴全）【我这次改了什么】（大白话）
请回答：1. 这条测试原本保护什么行为 2. 我改动是"不小心破坏原行为"还是"需求真变了" 3. 前者告诉我校哪、怎么改回 4. 后者告诉我测试怎么更新，并写一句提交说明讲清为什么变。
请不要默认"改测试让它通过"是正确答案。

79 篇速查卡

下篇预告

测试是机器帮你盯”结果对不对”。但有一大类问题机器盯不到：密钥写代码里、用户输入原样拼查询、循环里一遍遍查库、错误信息把内部结构吐给前端——这些代码全跑通、测试全绿，可迟早出事。这类本靠有经验同事帮你看，可你没有那个同事呢？下一篇《第 80 篇：用 AI 做 Code Review》教你把 AI 变成那个同事。下篇见。