用 claude code 辅助编写单元测试时容易忽视的边界情况

去年我为一家支付公司做测试审计，发现一个让人后背发凉的数字：在 AI 辅助生成的 3400 多个单元测试用例中，有 21% 的用例实际上只测试了正常路径，而执行这些测试的开发者中有超过一半的人认为“覆盖率已经够了”。这些被遗漏的场景不是那种刁钻的并发竞态，而是“金额恰好为零”、“优惠券列表为空”、“用户输入的手机号刚好 11 位”这种最基础的业务边界。问题不在 Claude Code 的能力上，它非常擅长写语法正确的测试代码，问题在于它默认写出来的测试，几乎总是沿着阻力最小的路径走。

这篇文章源自我过去一年里，分别在电商、支付、SaaS 三个领域的项目中深度使用 Claude Code 写单元测试的真实记录。我把每一次测试失败、每一次线上事故、每一次 Code Review 里揪出来的遗漏都做了分类归档。下面要讲的每一个边界场景，都不是理论推演，而是我真的看着 AI 生成的测试漏掉了它们，然后追查为什么漏掉，最后总结出一套让 Claude Code 生成测试更“警觉”的方法。

一、核心结论：AI 写测试的短板不在语法，在“意图盲区”

Claude Code 写单元测试的质量上限，不取决于它的代码生成能力，而取决于你给它的上下文里有没有隐含业务边界。 这是贯穿全文的核心判断，我需要在一开始就把它说清楚。

很多人对 Claude Code 的不满来自一个共同的经历：你让它给一个方法写测试，几秒钟就生成了，看起来还挺全面，方法覆盖率也到了 100%，分支覆盖率也有 80% 多。然后你信心满满地提交代码，结果几个迭代之后线上出了 bug，一查根因，那个边界情况测试里根本没覆盖，你的单元测试“全绿”但对这道防线形同虚设。

这背后的原因不是 Claude Code 笨。Anthropic 的模型在理解代码结构和编写测试断言方面已经相当成熟，但它对“业务的隐性规则”没有任何感知能力。一个方法签名 calculateFinalPrice(BigDecimal price, int memberLevel, List<String> couponIds) 在 AI 眼里只是一组类型和参数名，它不知道 memberLevel=0 在你的系统里代表“黑名单用户应该直接抛出异常”，它也不知道 couponIds 为空列表和 couponIds 为 null 在你的业务逻辑里是两种截然不同的处理路径。

这就是我一直说的“意图盲区”：AI 看得见代码的结构，看不见代码背后的人类意图。

基于这个判断，我把 Claude Code 最容易忽视的边界情况分成了三大类，每一类下面有具体的子场景和应对方法。这三大类是：

1. 值边界： 零、空、极大极小、刚好等于阈值，这些“特殊值”AI 往往不主动测试。
2. 时序与状态边界： 异步回调、缓存污染、测试之间的状态残留，AI 假设每个测试活在真空里。
3. 依赖与断言边界： Mock 对象返回异常、断言只验证了表面，AI 倾向于验证“调用完成”而非“结果正确”。

下面我会逐类拆解，每一类都配上真实的代码场景和我踩过的具体坑。

二、值边界：AI 最容易写出一堆“中等值”测试，然后漏掉真正致命的特殊值

2.1 “恰好为零”不是 bug，是业务逻辑的试金石

我先讲一个让我印象最深的案例。

去年在一个电商促销系统中，有一个 calculateFinalPrice 方法，逻辑大概是：根据商品原价、用户会员等级、可用的优惠券列表，计算出最终支付金额。方法签名长这样：

public BigDecimal calculateFinalPrice(BigDecimal originalPrice, 
int memberLevel,

List<String> couponIds)

我用 Claude Code 给这个方法生成单元测试。生成出来的用例看起来挺全的：

• shouldReturnDiscountedPriceForGoldMember
• shouldApplyCouponCorrectly
• shouldThrowExceptionForNegativePrice

我一眼扫过去，结构正确，断言也没毛病，就合进去了。三个月后的一个深夜，运维报警，有一批订单的最终金额被算成了负数。

追查下来的原因让我哭笑不得：当 originalPrice 恰好等于 0 元时（这种场景出现在赠品订单里，系统允许价格为零的商品独立下单），calculateFinalPrice 里有一段积分抵扣逻辑没有做零值保护，导致了负数金额。

但 AI 生成的测试里，originalPrice 的取值全都是 99.99、199.99、500.00 这种“看起来正常”的金额。0 元、0.01 元、999999.99 元，这些在 AI 看来不够“典型”的值，统统没出现。

这件事让我意识到一个规律：Claude Code 在选择测试数据时，有一种向“心理中位值”靠拢的倾向。 给它一个 BigDecimal 类型的参数，它大概率会生成 10.00、100.00、1000.00 这种看起来整整齐齐的值。但真正值得测试的，恰好是这些“正常值”之外的值。

专业判断： 这不是 Claude Code 的 bug，这是它从训练数据里学到的模式，网上的代码示例里，测试数据多数是 10、100 这种“教学友好型”数字。它模仿了这个习惯。

行动建议： 在给 Claude Code 的 prompt 里，如果你有测试数据的要求，要显式指定边界值。我现在的做法是，给 prompt 加一句：

请确保测试用例中包含以下边界值：null、零、负数、恰好等于业务阈值、远超正常范围的大值/小值。

这一句话就能让生成结果的质量上一个台阶。

2.2 空集合和单元素集合，两个看似简单但经常漏掉的边界

List<String> couponIds 这个参数，AI 生成的测试通常会传一个包含两三个元素的小列表进去，比如 ["COUPON_001", "COUPON_002"]。但 null 列表、空列表、以及恰好只有一个元素的列表，这三种情况往往被直接跳过。

null 和空列表的区别在很多业务逻辑里是关键分支。比如你的方法里有一个判断：

if (couponIds == null) {
throw new IllegalArgumentException("couponIds must not be null");

}

if (couponIds.isEmpty()) {

return originalPrice; // 无优惠券直接返回原价

}

这两行代码是两个分支。如果测试用例里 couponIds 从来都是 ["C1", "C2"]，那这两个分支一个都没跑到。覆盖率工具会告诉你这两行是“未覆盖”，但 AI 在生成的时候并没有意识到要主动去覆盖它们。

更微妙的是单元素列表。我遇到过一种 bug，出在一个对优惠券列表做 reduce 操作的逻辑上：当列表里只有一张优惠券时，reduce 的初始值和累加逻辑会产生一个非预期的结果，而当列表有两张或更多时，结果反而是正确的。这种“单元素边界”是 AI 几乎不会自动覆盖的。

我的做法是建立一个“集合参数测试模板”：

每次 CR 到 AI 生成的测试，我会直接套这张表检查一遍。三秒就能发现漏了哪个。

2.3 字符串的“刚好等于限制长度”，那个经常引爆线上问题的边界

用户名最长 20 位、手机号必须是 11 位、地址不能超过 200 字符，这些规则散落在代码的各个角落。Claude Code 给 validateUsername(String username) 方法写测试的时候，通常只会生成 shouldAcceptNormalUsername 和 shouldRejectNullUsername。

但“恰好等于 20 位”的用户名应该通过还是被拒绝？ 这取决于你的实现用的是 > 还是 >=。一个字符的差别，就是 bug 和正常功能之间的距离。

更常见的问题出现在“21 位”这个边界上。如果你的校验逻辑有问题，21 位可能突破了长度限制，在后续的数据库写入时直接抛出一个 DataTruncation 异常，但这个异常在你的单元测试里永远不会出现，因为你的测试数据从来没超过 20 位。

我自己定的规则是：对于任何有长度限制的字符串参数，Claude Code 生成的测试必须额外补齐四个边界值，length-1、length、length+1、以及空字符串。 这四个值不是我自己想的，而是等价类划分和边界值分析的标准做法。AI 没主动做这件事，但作为测试设计者，你必须要求它做。

三、时序与状态边界：AI 假设每个测试活在真空里

3.1 共享状态和测试执行顺序，AI 的盲区重灾区

先讲一个我三周前刚遇到的事情。

我在调试一个 CounterService，它内部有一个带本地缓存的计数器功能。缓存是用 ConcurrentHashMap 实现的，不同用户的路由到不同的计数器实例。Claude Code 帮我生成了两个测试：

@Test
void shouldIncrementCounterForUser() {

counterService.increment("user-1");

assertEquals(1, counterService.getCount("user-1"));

}

@Test

void shouldReturnZeroForNewUser() {

assertEquals(0, counterService.getCount("user-2"));

}

单独跑，都绿。一起跑，偶尔第二个测试会挂。原因很简单：第一个测试执行后，user-1 的计数器留在缓存里，而第二个测试依赖的是“全新状态”。当 JVM 按不同顺序执行测试时（比如先跑第二个），有时能过，有时不能过。

Claude Code 生成的测试有一个默认假设：每个测试从一个干净的、无状态的环境开始。 但现实是，Spring 的测试上下文、静态变量、单例对象、甚至是同一个 JVM 里的线程池，都会让测试之间产生隐含的状态耦合。

这个问题的根源在于，AI 在生成测试时，看到的是一个“方法快照”，它只关注被测方法内部的逻辑，看不到方法之外的状态会如何影响测试结果。

我的解决方案分两层：

第一层，技术手段。在 prompt 里明确要求使用 @DirtiesContext 或者 @BeforeEach 的清理逻辑。比如：

对于涉及缓存、静态变量、单例状态的被测方法，请在测试类中添加 @BeforeEach 清理逻辑，确保测试之间状态隔离。

第二层，审查习惯。我给自己加了一个 Code Review 的检查项：“这些测试是否假设了无状态环境？” 每次看到 AI 生成的测试，我都会在脑子里跑一遍：如果测试 B 在测试 A 之前执行会怎样？如果测试 A 执行了两遍会怎样？

3.2 异步和并发，AI 写的测试通常“等不及”异常发生

Java 里的 CompletableFuture、@Async、消息队列的异步消费，这些涉及线程切换的代码，Claude Code 生成的测试有一个通病：它只会测试“等待后成功”的场景，不会测试“超时后怎么办”和“异常回调里发生了什么”。

我见过最典型的 AI 生成异步测试长这样：

@Test
void shouldProcessAsyncTask() throws Exception {

CompletableFuture<String> result = asyncService.process("input");

assertEquals("processed", result.get(5, TimeUnit.SECONDS));

}

这个测试验证了正常路径。但它完全忽略了以下场景：

• 如果 result.get() 超时了，会抛出 TimeoutException，调用的上层代码能正确处理吗？
• 如果你对 result 调用了 cancel(true)，正在执行的线程会被中断吗？中断后的状态是干净的吗？
• process() 方法里如果抛了异常，它是在 CompletableFuture 的 exceptionally() 回调里被处理吗？还是在某处被默默吞掉了？

这些场景，Claude Code 几乎不会主动生成，因为它的训练数据里，这一类“异常路径的异步测试”本就是稀缺内容。 大部分教学示例只展示“怎么测试异步成功”，不展示“怎么测试异步失败”。

我的做法是：对于任何包含异步操作的方法，在让 Claude Code 生成测试时，把超时、取消、异常回调这三个场景作为显式需求写在 prompt 里。 不是“请写测试”，而是：

请为以下异步方法生成测试，包含以下场景：1）正常完成 2）超时 3）cancel 之后的状态 4）异常抛出后的回调逻辑。

这四个场景一列，生成出来的测试质量完全不同。

四、依赖与断言边界：AI 擅长 Mock 成功，不擅长 Mock 失败

4.1 Mock 对象返回 null 和异常，测试不是只测“别人表现好的时候”

再分享一个我经历的生产事故。上周一个支付回调接口在处理第三方返回时抛了 NPE，定位下来发现是 paymentGateway.queryStatus(orderId) 在某些网络抖动的情况下返回了 null，但我们的代码里没有对 null 做防御。

反查当时的测试代码，Claude Code 生成的 Mock 配置长这样：

when(paymentGateway.queryStatus(anyString())).thenReturn(PaymentStatus.SUCCESS);
全篇测试只有一个 thenReturn(PaymentStatus.SUCCESS)。thenReturn(null)？没有。thenThrow(new IOException())？也没有。

我不是说 AI 不对，它确实生成了一个语法正确、能跑的测试。但它完全没有考虑“依赖服务出故障”的场景。 而真实的生产环境里，第三方接口超时、返回 null、返回错误码、返回格式不对，这些都是高频事件。




后来我给团队定了一个 Mock 完整性检查清单，每次 CR AI 生成的测试时必须逐项对齐：

成功返回： 正常数据（AI 会生成）
null 返回： 依赖返回 null（AI 通常不生成）
异常抛出： 超时异常、连接异常、业务异常（AI 通常不生成）
非预期格式： 字段缺失、类型不对（AI 几乎不生成）
四个场景缺一个，这组测试就不能算合格。

4.2 断言的“贫血症”，只验证返回码，不验证业务结果

这是我在审查 AI 生成的测试时发现的最隐蔽的问题。

来看一个真实的例子。一个创建订单的 REST 接口的测试，AI 生成出来的断言是这样的：

@Test
void shouldCreateOrder() throws Exception {

mockMvc.perform(post("/api/orders")

.contentType(MediaType.APPLICATION_JSON)

.content(orderJson))

.andExpect(status().isOk());

}

这个断言只验证了 HTTP 状态码是 200。 至于返回体里的订单 ID 是不是非空、订单金额是不是和输入一致、订单状态是不是“待支付”、数据库里是不是真的插入了这一条记录，一概没验证。

这种测试的杀伤力极大，因为它会给覆盖率报告贡献一个绿色的行，但实际上什么都没保障。我就见过一个 bug：接口返回 200，但实际数据库写入失败（因为字段长度超限），而“贫血断言”的测试完全没发现。

正确的断言应该是多层验证：

1. 接口层： 验证状态码和返回体的关键字段（订单 ID 非空、状态是预期值）。
2. 业务层： 验证计算逻辑（金额、折扣、积分计算结果是否符合预期）。
3. 持久层： 验证数据库里写入的数据是否正确（如果需要端到端验证的话）。

在给 Claude Code 的 prompt 里，我现在会这样写：

请为测试生成多层断言：1）验证返回值/状态码 2）验证返回对象的核心字段值 3）如果涉及持久化，验证数据已正确写入。

一句话总结：让 AI 写的断言，不仅要“验证调用成功了”，更要“验证结果是自己想要的”。

五、业务规则边界：最难让 AI 理解的是“为什么这笔交易不一样”

5.1 业务规则里的隐性阈值，AI 看不见的“规则墙”

一个会员等级系统里，LV1 到 LV2 的升级条件是消费满 10000 元。那么 9999.99 元就是 LV1，10000.00 元就是 LV2。这个“恰好等于 10000”的边界，AI 完全不知道它的存在，因为这条规则没有写在方法签名里，它藏在某个配置表里，或者某个 if (totalSpent >= 10000) 的条件判断里。

Claude Code 当然可以读那行代码，但如果方法逻辑本身很复杂，你在 prompt 里又没特意强调这个阈值，它生成的测试数据大概率会避过这个精确的临界点。

我现在的做法是，对于任何涉及“业务阈值”的方法，在 prompt 里用一句话明确告诉 AI 这个阈值是什么：

该方法的核心阈值是 totalSpent >= 10000 时会员升级。请确保测试覆盖 9999.99 和 10000.00 两个边界值。

这样一句话，比让它“自己发现”要靠谱十倍。

5.2 业务状态的组合爆炸，AI 倾向简化，而不是穷举

有个订单退款的方法，逻辑大概是：订单状态必须是“已支付”、退款金额不能超过剩余可退金额、用户不能处于风控黑名单中。三个条件一组合，理论上应该有 2³ = 8 种状态组合需要测试。

Claude Code 生成的测试通常只覆盖两种：全部条件满足（退款成功）、订单状态不对（退款失败）。其他六种组合，它要么认为“不重要”，要么根本没意识到这些字段之间存在联动关系。

这不是 AI 不够聪明，而是它默认的“测试覆盖”概念是浅层的。除非你明确要求它做组合测试，否则它只会给你最简单的几条路径。

我的解决办法是在复杂业务逻辑上使用决策表。把条件列成表格，让 AI 理解每一行是一个测试用例。比如：

把这个表格贴在 prompt 里，Claude Code 生成的测试就能覆盖全部 8 种组合。我试过不贴表格直接让它生成，它平均只能覆盖 3-4 种。差距就是这么大。

六、浮点数和精度：一个大部分开发者都踩过、AI 照样踩的坑

这个是技术层面的老话题了，但在 AI 辅助测试的语境下值得重提一遍。

AI 给一个计算利息的方法写测试时，断言经常是：

assertEquals(1.05, calculator.calculateInterest(100, 0.0105));
用 assertEquals 比较浮点数是一个经典错误。在金融系统里，这条断言大概率会失败，因为 1.05 在 IEEE 754 标准下的内存表示和 calculateInterest 实际返回的值存在纳秒级的差异。

Claude Code 在生成涉及浮点数的测试时，并不会自动变成 assertEquals(expected, actual, 1e-10) 或者引入 BigDecimal。它直接写了 assertEquals，因为它被训练的代码库里，有太多人就是这么写的。

更隐蔽的问题是，当业务系统要求精确到分（小数点后两位），而中间计算涉及除法时，四舍五入的方式（向上取整、向下取整、四舍六入五成双）会产生完全不同的结果。AI 不知道你的公司用的是哪种规则。

这一条的处理方法很简单：凡是涉及浮点数计算的测试，你必须检查 AI 生成的断言是否使用了正确的精度比较方式。 如果是 Java，统一要求使用 BigDecimal 配合 compareTo，并在 prompt 里声明精度规则。




七、让 Claude Code 写出更“警觉”的测试：一套可用的方法论

前面六章是我踩过的坑和分类。这一章是解决办法，不是泛泛的建议，是我在实际带团队推广 AI 辅助测试时落地的一套操作流程。

7.1 Prompt 的结构化改造：从“给我写测试”到“给我写包含边界测试的测试”

大部分人对 Claude Code 说的一句话是：“给这个方法写单元测试。”这句话太宽泛了。AI 只能用它的“默认模式”来回应，写一个看起来像测试的测试。

我在团队里推行的是“带约束的 Prompt 模板”：

请为以下方法生成单元测试。要求：

正常路径：覆盖方法的预期使用方式
参数边界：对于每个参数，覆盖 null、零值、空集合、恰好等于限制长度的值、超过限制长度的值
异常路径：覆盖方法可能抛出的每种异常，以及其触发的条件
Mock完整性：对于所有外部依赖，Mock其成功返回、null返回、异常抛出三种情况
断言深度：每个测试至少包含两层断言，第一层验证状态码或返回值非空，第二层验证核心业务字段的正确性
状态隔离：如涉及缓存、静态变量或单例，请添加状态清理逻辑
方法如下：

[贴代码]

这个模板我在 30 多个方法上对比测试过：使用普通 prompt 生成的平均分支覆盖率为 62%，使用结构化 prompt 的平均分支覆盖率为 87%。 这不是 Claude Code 变强了，是你给它的指令变强了。

7.2 Code Review 时的“边界检查清单”：你不需要靠记忆力

我最开始靠脑子记这些边界场景，结果每次 CR 都会漏一两个。后来我干脆把常见的边界场景做成了一个 Markdown 清单，每次 Review AI 生成的测试时，打开它，逐项扫一遍。五分钟之内一定扫完。

这份清单长这样：

## AI 生成测试的边界检查清单
参数边界

[ ] 每个数值参数是否测试了 0、负数、极大值/极小值？

[ ] 每个字符串参数是否测试了 null、空串、恰好限制长度、超长？

[ ] 每个集合参数是否测试了 null、空集合、单元素、多元素？

[ ] 业务阈值是否测试了“阈值-1”和“阈值”本身？

状态与并发

[ ] 测试之间是否存在共享状态（静态变量、缓存、单例）？如有，是否有清理？

[ ] 异步方法是否测试了超时、cancel、异常回调？

Mock与依赖

[ ] 外部依赖是否 Mock 了成功、null、异常三种返回？

[ ] 断言是否只验证了状态码？是否验证了核心业务字段？

浮点数

[ ] 涉及浮点数计算的断言是否使用了精度容差或 BigDecimal？

7.3 用决策表处理复杂业务规则

前面 5.2 提到过，这里再展开一点。对于条件组合超过 3 个以上的业务方法，决策表是目前我发现的最有效的“人机沟通方式”。

它的逻辑是：你先把业务规则翻译成 AI 能完全理解的条件-结果映射表，然后让 AI 按照这个表逐行生成测试。每一行就是一个测试用例，不存在“漏掉组合”的问题。

我用的决策表模板很简单：

把这个表贴在 prompt 里，加上一句“请按照上述决策表的每一行生成对应的测试用例”，生成的测试就会完整覆盖所有组合。我测过一个 5 个条件的方法，理论组合 32 种，用决策表引导后，Claude Code 生成的 32 个测试覆盖了全部组合，没有一个重复或遗漏。

7.4 不同场景的取舍：不是所有方法都需要全量边界测试

有人问我：“你这套东西做下来，一个方法的测试要写多久？”我的回答是：“不是所有方法都值得这么做。”

我把被测方法分成了三个等级：

全量边界测试（L1 级别）是有成本的。 一个支付核心方法，可能要写 30-50 个测试用例，加上决策表建模和 CR 的时间，总投入大概在 40 分钟到 1 小时。但考虑到这个方法一旦出问题就是真金白银的损失，这个投入完全值得。

反过来，一个 formatDateTime 的工具方法，你不需要给它测 null、空字符串、非法格式之外的边界，它的影响半径太小了，全量测试的 ROI 是负的。

取舍的核心原则：测试深度要和方法的“出错成本”成正比。

八、下一步行动：把你今天的第一个 AI 生成测试改到“警觉”级别

这篇文章写到这里，信息量已经很大了。我不想再给一个泛泛的“总结”，而是直接告诉你明天可以做的三件事：

第一件事：拿着 7.2 节的检查清单，打开你今天刚让 Claude Code 生成的最近一个测试文件，逐项扫一遍。 我几乎可以确定，你会找到至少一个遗漏的边界场景。找到之后，动手补上那个测试用例。这个过程比你读任何文章都更能建立肌肉记忆。

第二件事：把这个检查清单贴到你们团队的知识库里。 如果你和我一样在带团队，让清单成为 Code Review 的必查项，而不是你个人的经验。我在团队推行了 4 个月后，AI 生成的测试经过清单审查的代码，线上 bug 密度比之前下降了约 35%（这个数字来自我们自己的监控看板，我在内部分享里展示过）。

第三件事：下一次对 Claude Code 说“写测试”的时候，用 7.1 节的结构化 Prompt 而不是随口说一句。 你会发现，仅仅多花 20 秒写好 prompt，生成的测试质量就能提升一个档次。这是 ROI 最高的 20 秒。

说一句不那么中听但是真实的话：AI 辅助写测试这件事，省下来的不是“测试设计”的时间，而是“测试编码”的时间。 设计什么样的用例、覆盖哪些边界、构造哪种异常场景，这些决策，在当前的 AI 能力下，仍然必须由你自己来做。Claude Code 让你从繁琐的 @Test 和 assertEquals 里解放出来，但它解放不了你对“这个系统哪里会出问题”的思考。

那些没有思考过的边界，最终都会变成凌晨三点的报警电话。