用于边界用例的 Claude Code 测试生成提示

为什么只写 happy-path 测试浪费时间

自动生成的测试套件看起来常常很惊人：几十个测试、大量设置代码、每个函数名都出现过。但许多测试只是“在一切正常时能工作”的检查。它们容易通过，很少发现 bug，而且仍然增加阅读与维护成本。

使用典型的 Claude Code 测试生成提示时，模型倾向于反映它看到的示例输入。你会得到看似不同但覆盖相同行为的变体。结果是一个庞大的测试套件，但在关键处覆盖薄弱。

高信号测试不同。它们是能在上个月事故中发现问题的那小部分测试。它们会在行为以风险方式改变时失败，并在无害重构时保持稳定。一个高信号测试的价值可能抵得上二十个“返回期望值”式的检查。

低价值的 happy-path 生成通常有几个明显特征：

• 许多测试只在输入标签上不同，而不是在可能出错的地方不同。
• 断言很浅（“不为 null”、“状态是 200”），没有校验含义。
• 设置比被测试的行为更复杂，导致人们停止更新测试。
• 覆盖率看起来很高，但边缘情况未被触及。

想象一个应用折扣码的函数。happy-path 测试确认 “SAVE10” 会降低价格。真正的 bug 隐藏在别处：0 或负价格、已过期的码、四舍五入边缘或最高折扣上限。这些才是导致错误总额、愤怒客户和午夜回滚的情况。

目标是从“更多测试”转向“更好的测试”，聚焦三类目标：边界、故障模式和不变量。

三个目标：边界、故障模式、不变量

如果你想要高信号的单元测试，不要再要求“更多测试”，而是开始要求三类特定的测试。这就是能产生有用覆盖而不是一堆“正常输入可用”检查的 Claude Code 测试生成提示的核心。

1) 边界（bug 常藏身处）

边界是代码接受或产生的边缘。许多真实缺陷是 off-by-one、空状态或超时问题，在 happy path 下不会出现。

以最小值和最大值为思路（0、1、最大长度）、空 vs 有（""、[]、nil）、越界一位（n-1、n、n+1）和时间限制（接近截止）。

示例：如果一个 API 接受“最多 100 项”，请测试 100 和 101，而不仅仅是 3。

2) 故障模式（证明系统能安全失败）

故障模式是系统可能崩溃的方式：错误输入、缺失依赖、部分结果或上游错误。好的故障模式测试会检查在压力下的行为，而不仅仅是理想条件下的输出。

示例：当数据库调用失败时，函数是否返回明确错误并避免写入部分数据？

3) 不变量（必须始终成立的规则）

不变量是在调用前后应始终为真的事实。它们把模糊的正确性变成明确的断言。

示例：

• “余额在任何取款操作后都不能为负”。
• “ID 保持唯一”，即使你快速创建多个条目。
• “发生错误时不改变状态”（没有新行、没有标志翻转）。

当你把注意力放在这三类目标时，你会得到更少的测试，但每个测试的信号更强。

准备：在写测试前抽取一个小契约

如果你太早就请求生成测试，通常会得到一堆礼貌的“按预期工作”检查。一个简单的修正是先写一个小契约，然后基于该契约生成测试。这是把 Claude Code 测试生成提示变成能发现真实 bug 的最快方法。

一个有用的契约短到能一口气读完。目标是 5 到 10 行，回答三个问题：输入是什么、输出是什么、还有什么其他变化。

一个 5–10 行的契约模板

用简单语言写契约，不要用代码，并只包含你能够测试的内容。

• 输入：类型、允许范围以及什么算“空”或“缺失”。
• 输出：返回值或错误形状，以及“成功”保证的含义。
• 副作用：状态、数据库行、网络调用、文件、日志的变化。
• 假设：调用者常犯的错误（时区、编码、鉴权、顺序）。
• “绝不发生”：崩溃、静默数据丢失、双重收费、部分写入、信息泄露。

一旦有了这些，扫描哪些地方现实会打破你的假设。那些就成为边界情况（最小/最大、零、溢出、空字符串、重复）和故障模式（超时、权限拒绝、唯一约束冲突、损坏输入）。

下面是针对类似 reserveInventory(itemId, qty) 功能的具体示例：

契约可能写明 qty 必须是正整数，函数应当原子执行，并且绝不能产生负库存。这会立刻提示高信号测试：qty = 0、qty = 1、qty 大于可用量、并发调用、以及在数据库中间故意出错的情形。

如果你使用像 Koder.ai 这样以对话驱动的工具，同样的工作流程适用：先在聊天中写契约，然后生成直接攻击边界、故障模式和“绝不发生”清单的测试。

提示模式：高信号测试蓝图

当你想要更少但每个都很重要的测试时，使用这个 Claude Code 测试生成提示。关键步骤是先强制生成测试计划，然后在你批准计划后才生成测试代码。

You are helping me write HIGH-SIGNAL unit tests.

Context
- Language/framework: <fill in>
- Function/module under test: <name + short description>
- Inputs: <types, ranges, constraints>
- Outputs: <types + meaning>
- Side effects/external calls: <db, network, clock, randomness>

Contract (keep it small)
1) Preconditions: <what must be true>
2) Postconditions: <what must be true after>
3) Error behavior: <how failures are surfaced>

Task
PHASE 1 (plan only, no code):
A) Propose 6-10 tests max. Do not include “happy path” unless it protects an invariant.
B) For each test, state: intent, setup, input, expected result, and WHY it is high-signal.
C) Invariants: list 3-5 invariants and how each will be asserted.
D) Boundary matrix: propose a small matrix of boundary values (min/max/empty/null/off-by-one/too-long/invalid enum).
E) Failure modes: list negative tests that prove safe behavior (no crash, no partial write, clear error).
Stop after PHASE 1 and ask for approval.

PHASE 2 (after approval):
Generate the actual test code with clear names and minimal mocks.

一个实用技巧是要求以紧凑表格形式给出边界矩阵，这样明显的空缺一目了然：

如果 Claude 提出 20 个测试，请反驳。要求它合并相似案例，只保留那些能发现真实 bug（越界一位、错误的错误类型、静默数据丢失、破坏不变量）的测试。

逐步操作：运行提示并把输出变成测试

先用一个小且具体的契约描述你想要的行为。粘贴函数签名、对输入输出的简短描述，以及任何现有测试（即便只是 happy-path）。这可以让模型锚定在真实代码上，而不是它猜测的行为。

接着，在要求生成任何测试代码之前，先要求一个风险表。要求三个列：边界用例（输入的边缘）、故障模式（坏输入、缺失数据、超时）和不变量（必须始终为真的规则）。每行加一句“为什么这会导致失败”。一个简单表格比一堆测试文件更快地揭示空白。

然后选择最小的一组测试，使每个测试都有独特的抓 bug 目的。如果两个测试因同一原因失败，保留更强的那个。

一个实用的选择规则：

• 保留覆盖不同边界的测试（最小、最大、空、越界一位）。
• 保留证明在故障下安全行为的测试（明确错误、无部分写入、无崩溃）。
• 保留断言不变量的测试（顺序、总额、幂等性、无重复）。
• 删除仅重复“在正常输入下可用”的测试。

最后，为每个测试要求一段简短说明：如果该测试失败，会捕获到什么 bug。如果说明含糊（“验证行为”），该测试可能是低信号的。

如何把不变量编码成断言

不变量是无论输入为何都应保持真实的规则。用不变量驱动测试时，先把规则写成一句短句，然后把它变成一个能明显失败的断言。

挑 1–2 个实际能保护你的不变量。好的不变量通常关于安全（无数据丢失）、一致性（相同输入相同输出）或上限（不超过限制）。

把不变量变成可证明的检查

把不变量写成短句，然后决定测试能观测到什么证据：返回值、持久化数据、发出的事件或对依赖的调用。强有力的断言同时检查结果和副作用，因为很多 bug 隐藏在“返回 OK 但写错了东西”里。

例如，对一个将优惠券应用于订单的函数：

• 不变量：最终总额永远不为负。
• 不变量：同一张优惠券重复应用不会重复折扣。

现在把它们编码为具体断言：

expect(result.total).toBeGreaterThanOrEqual(0)
expect(db.getOrder(orderId).discountCents).toBe(originalDiscountCents)

避免模糊的断言如“返回期望结果”。断言具体规则（非负）和关键副作用（只记录一次折扣）。

为不变量加上反例说明以保持测试锋利

对每个不变量，在测试中加一句简短注释说明什么数据会违背该不变量。这可以防止测试日后退化成 happy-path 检查。

一个简单且持久的模式：

• 在测试名称中写出不变量。
• 在输出上断言不变量。
• 断言关键副作用（或无副作用）。
• 添加一条注释说明一个可能的违例（例如超大优惠券值或重复应用）。

故障模式：写能证明安全失败的测试

高信号测试常常是确认代码能安全失败的那些测试。如果模型只写 happy-path 测试，你对功能在输入或依赖混乱时的行为几乎一无所知。

先决定对于该功能“安全”是什么意思。它是返回一个有类型的错误？回退到默认值？重试一次然后停止？把期望行为写成一句话，然后让测试证明它。

当你向 Claude Code 请求故障模式测试时，目标要严格：覆盖系统可能崩溃的方式，并断言你想要的确切响应。一句有用的话是：“偏好更少但断言更强的测试，而不是很多浅断言的测试。”

常见能产出最佳测试的故障类别：

• 错误输入：无效格式、缺少必填字段、超出范围的值
• 依赖失败：超时、500、空响应、损坏的负载
• 顺序问题：乱序事件、重复、部分写入
• 并发：更新竞争、幂等性校验
• 恢复行为：何时返回错误 vs 回退 vs 重试

示例：有一个创建用户并调用邮件服务发送欢迎邮件的端点。低价值的测试检查“返回 201”。高信号的故障测试检查当邮件服务超时时，你是 (a) 仍创建用户并返回 201 同时标记为“email_pending”，还是 (b) 返回明确的 503 并且不创建用户。选定一种行为，然后断言响应和副作用。

还要测试不会泄露什么信息。如果校验失败，确保没有写入数据库。如果依赖返回损坏负载，确保你不会抛出未处理异常或返回原始堆栈跟踪。

导致低价值测试的常见陷阱

低价值的测试集通常发生在模型被奖励创造数量时。如果你的 Claude Code 测试生成提示要求“20 个单元测试”，你常会得到仅在字符串或数字上微小变化的重复测试，表面看起来覆盖很广但实际上没捕获新问题。

常见陷阱：

• 相似测试：相同的“有效输入”测试，用不同字符串或数字重复出现。
• 测试镜像实现：断言私有步骤或 helper 调用，而不是可观测行为。
• 全部模拟：一次性替换数据库、时钟、网络和配置。
• 弱断言：只检查“无错误”、“非空”或“状态 200”。
• 留下脏的共享状态：遗留种子数据、修改的全局变量或缓存值。

示例：假设有一个“创建用户”函数。十个 happy-path 测试可能只是改变邮箱字符串，仍然错过重要内容：拒绝重复邮箱、处理空密码并保证返回的用户 ID 唯一且稳定。

有助于审查的护栏：

• 要求每个测试命名它所覆盖的风险（边界、故障模式或不变量）。
• 避免仅实现级别的检查，除非它们改变了可观测行为。
• 保持最少的模拟，并在可行时允许少量直连集成测试。
• 要求强断言：精确输出、状态变化和错误类型/消息。
• 添加清理规则，保证测试不依赖执行顺序。

示例：把一个功能变成一组小而强的测试

想象一个功能：在结账时应用优惠券代码。

契约（小且可测试）：给定以分为单位的购物车小计和可选优惠券，返回以分为单位的最终总额。规则：百分比优惠向下取整到最接近分，固定优惠减去固定金额，总额绝不低于 0。优惠券可能无效、过期或已被使用。

不要只问“为 applyCoupon() 写测试”。要针对该契约要求边界用例测试、故障模式测试和与该契约相关的不变量。

强制触发边界行为的边界

选择容易破坏数学或校验的输入：空的优惠码字符串、小计 = 0、刚好低于和高于最低消费、小计小于固定折扣、以及像 33% 这样的百分比导致四舍五入问题。

证明安全失败的故障模式

假设优惠券查找可能失败或状态可能错误：优惠券服务宕机、优惠券过期、或该用户已兑换该券。测试应证明接下来会发生什么（优惠被拒绝且返回明确错误、总额不变）。

一个最小但高信号的测试集合（5 个测试）以及每个测试能捕获的问题：

• 拒绝空或仅空白的代码：捕获“把空当有效”或修剪错误的 bug。
• 百分比优惠舍入（小计 101，33%）：捕获舍入错误与一分钱 off-by-one 的问题。
• 固定折扣大于小计（小计 500，折扣 1000）：证明总额不会变为负数的不变量。
• 最低消费边界（小计 999 vs 1000）：捕获错误的比较逻辑（< vs <=）。
• 优惠券查找失败或超时：证明安全回退（不应用折扣）与稳定的错误处理。

如果这些都通过，你就覆盖了常见的断点，而不必用重复的 happy-path 测试填满套件。

用 AI 生成高信号测试的快速检查清单

在接受模型生成结果前，做一次快速质量检查。目标是每个测试都在保护你免受具体且可能发生的 bug。

把这个检查表作为门槛：

• 每个输入字段的边界：对每个输入字段（字符串、ID、时间戳、标志）至少包含一个边界用例（空 vs 仅空白、最大长度、零 vs 负、缺失可选字段、越界一位）。
• 依赖失败：至少包含一个依赖异常行为的测试（数据库超时、第三方 API 500、过期鉴权）。证明安全行为（明确错误、无部分写入）。
• 带强断言的不变量：挑 1–3 个必须始终成立的规则并直接断言。避免“响应正常”这样的模糊断言。
• 每个测试捕获唯一的 bug：读每个测试标题并问，“如果它失败，会捕获哪个具体缺陷？”如果两个测试答案相同，把它们合并。
• 删除测试检查：尝试删除一个测试。如果没有丢失任何重要的边界/故障模式/不变量，它就不值得存在。

生成后一个实用技巧：把测试重命名为“should <行为> when <边界条件>”或“should not <坏结果> when <故障>”。如果不能干净地重命名，它们通常不够聚焦。

如果你在 Koder.ai 上构建，这个清单也很适合与快照和回滚结合使用：生成测试、运行、如果新的集合带来噪音而没有提升覆盖，则回滚。

下一步：把这个变成可复用的工作流程

把你的提示当作可复用的工具，而不是一次性请求。保存一份蓝图提示（强制边界、故障模式和不变量的那个）并在每个新函数、端点或 UI 流中重复使用它。

一个能快速提升结果的简单习惯：要求每个测试写一句话说明它会捕获什么 bug。如果这句话很泛泛，该测试很可能是噪音。

保持一份产品域不变量的活文档。别把它存在脑子里。每当你发现真实 bug 时就把它加入。

一个轻量的重复流程：

• 抽取一个微型契约：输入、输出、错误处理和 3–5 个不变量。
• 运行蓝图提示并请求边界、故障模式、不变量以及每项的一句理由。
• 实现覆盖不同风险的前 5–10 个测试。
• 重构，然后重新运行提示查看出现的新风险。
• 修剪重复并保留那些能发现过去事故的测试。

如果你通过聊天构建应用，把这个循环在 Koder.ai (koder.ai) 内运行，这样契约、计划和生成的测试都保存在一个地方。当重构意外更改行为时，快照和回滚能让你更容易比较并迭代，直到你的高信号集合保持稳定。