用claude code为遗留代码添加测试用例的覆盖策略

去年十月，我接手了一个运行了四年的支付系统。48个微服务、127万行Java代码、测试覆盖率8%。最让我失眠的不是代码烂，而是产品经理告诉我：双十一要做活动，涉及核心扣款逻辑的改动。我看着那个3000行的PaymentServiceImpl，没有任何单元测试，只有一份过期的接口文档，和三个“据说知道逻辑”的已离职同事的微信名片。

那是我第一次认真思考一个问题：面对遗留代码，到底是先重构还是先写测试？如果要写测试，从哪开始？AI能帮到什么程度？

三个月后，这个系统的核心模块测试覆盖率达到了76%，全年未发生P0级线上事故。在这个过程中，Claude Code扮演了关键角色，但不是“一键生成测试”的魔法棒，而是一个需要策略驾驭的工程工具。

这篇文章，就是我在那三个月里踩过的坑、建立的判断框架、以及反复验证后的覆盖策略。

核心结论先行：为遗留代码补测试，最重要的不是“怎么写”，而是“先写哪部分”和“写到什么程度”。 盲目追求覆盖率数字是危险的。你需要一个基于风险评级的覆盖策略，而Claude Code是这个策略的高效执行者，不是决策者。

一、为什么大多数“补测试”的努力都失败了，以及我的核心判断

在展开具体策略之前，我需要先澄清三个我在项目复盘时发现的深层问题。这些问题不解决，用什么工具都白费。

项目背景：一个典型的遗留系统“症状群”

我接手的这个系统，有一个典型的基因缺陷：它是由一个五人团队在8个月内从0搭建的，当时的需求是“尽快上线”。这意味着：

• 代码结构遵循“先写后想”的生理本能：所有逻辑堆在Service层，Controller直接调Service，Service直接调DAO，中间没有任何抽象层。
• 外部依赖像血管一样遍布全身：8个第三方支付通道、3个风控接口、2个账务系统、1个消息队列，且没有统一的防腐层设计。
• “能跑就行”的配置管理：数据库密码写死在application.yml里，支付回调URL在代码里拼接，不同环境的差异用注释来区分。

“给这种代码写测试”，这件事本身就让人绝望。因为你会发现，想要测试一个扣款方法，你至少需要mock掉5个外部调用，而且每个mock的数据结构都得去翻上生产日志才能搞清楚。

三个被忽视的深层原因

原因一：把“覆盖率”当成目标，而不是结果

我看到的教程、文章、工具厂商宣传，几乎都在暗示同一件事：用AI工具把覆盖率提到90%以上，你就安全了。

这完全错了。

在我项目的第二个月，Claude Code帮我为一个退款计算工具类生成了完整测试，覆盖率100%。两周后，线上出现了一笔超出应退金额的退款。排查发现，问题出在“部分退款含优惠券”的场景，Claude Code生成的测试用了一个合理的优惠券金额，但那个金额恰好绕过了我们券系统的核销校验逻辑。测试跑通了，覆盖率100%，但它测试的是一个不可能发生的场景，而真正的风险场景没有被覆盖。

覆盖率是滞后指标，不是你追求的目标。你真正要追求的是：每一个测试用例，都对应一个真实可能出现、且会导致业务损失的场景。

原因二：对遗留代码的“可测试性”缺乏评估

不是所有代码都值得直接写测试的。有些代码的耦合度如此之高，以至于强行写测试会让你陷入“Mock地狱”，大量的setUp代码、反射工具、PowerMock黑魔法，而最终测到的逻辑可能只有三行。

在这种代码上写测试，投入产出比极低。 正确的做法是先做一次轻量级重构，提取纯函数、引入接口隔离、拆分责任链，然后才是测试。但这个判断，AI做不了，它只能按照你的指令执行。

原因三：没有建立“测试价值密度”的评估体系

“测试价值密度”这个概念，是我在项目第三周提出的。简单说：不是所有代码的测试价值是均等的。

一个核心扣款算法的测试价值，和一个获取系统时间的DateUtil的测试价值，显然不同。但在遗留系统中，你很难一眼看出哪些代码是“高价值”的，因为它们通常散落在各个@Service里，被业务代码层层包裹。

因此，在让Claude Code开始工作之前，你必须先完成一件事：建立代码库的风险地图和价值分级。

二、第一步：建立遗留代码的“风险-价值”分级体系

这是我整个方法论中最关键的部分。跳过这一步直接让AI写测试，你会得到漂亮的覆盖率数字和一个依然脆弱的系统。

2.1 你的时间是有限的：为什么需要分级

假设你有一个10万行的遗留代码库，Claude Code可以在30秒内为一个文件生成测试。但你有3000个文件。即便全部自动化，审查这些生成的测试也需要大量时间。更关键的是，你只需要覆盖那些 “改动风险高、业务影响大、测试投入产出比合理” 的代码。

你不需要100%覆盖率。你需要覆盖率恰好覆盖住让你晚上睡不着觉的那部分代码。

2.2 两个维度、四个象限：我的分级框架

我通过两个维度来评估每一个模块：业务影响度和可测试性。

• 业务影响度： 如果这块代码出Bug，是否直接影响核心业务指标（交易额、资金安全、用户数据）？影响面是局部还是全局？
• 可测试性： 这块代码是否容易隔离测试？外部依赖是否可控？逻辑是否集中？

根据这两个维度，我把所有代码分入四个象限：

这个分级，是我所有后续决策的基础。 如果你跳过了这一步，你会发现自己花了一周，给一堆没人改的DTO写了200个测试，而核心支付逻辑依然裸露着。

2.3 如何操作：一个可执行的评估流程

我在项目中是这样执行的：

第一步：生成调用关系图（不依赖文档）

运行以下命令，让Claude Code读取整个模块结构：

claude --dangerously-skip-permissions "分析 src/main/java/com/xxx/payment 目录下的所有Java文件，
识别出：

被20个以上文件引用的类和方法（高影响度）

包含if-else分支超过30行的类（高影响度+高复杂度）

包含@Transactional注解且方法体超过200行的类（高影响度+潜在风险）

输出一个表格，包含类名、预估影响度、引用数量、关键风险点。"

这个过程在48个服务中识别出了113个高影响度模块。其中只有31个是可测试的（第一象限），剩下的82个需要不同程度的重构。

第二步：手工确认“业务影响度”

这不是AI能做的。你需要拉上你团队里最熟悉业务的那个人（可能是产品经理、也可能是那个还没离职的同事），逐个确认：这些模块如果坏了，账上会少多少钱？用户会看到什么？监管会找上门吗？

在我的项目中，这个确认过程花了两天。我们识别出12个最高优先级的模块，它们要么涉及资金流向，要么涉及合规上报，要么是用户可见的核心功能入口。

第三步：评估可测试性

这一步Claude Code可以帮忙，但最终判断靠人。我的判断标准是：

• 如果给这个方法写一个单元测试，我需要Mock几个外部对象？
• 如果大于3个，或者需要Mock静态方法/单例/私有方法，就属于低可测试性。
• 如果这个方法只依赖输入参数和明确的依赖接口，就属于高可测试性。

一个容易误判的场景： 有些类看起来依赖很多，但依赖都通过Spring注入，且Mock成本低。比如一个Service依赖了5个Repository，但每个Repository的方法都是标准的findById / save模式，Mock起来很轻松。这种类应该划入第一象限，而不是第二象限。 关键在于判断Mock的成本，而非Mock的数量。

三、第二步：为不同象限选择不同的覆盖策略

有了分级之后，策略就清晰了。但“清晰”和“可执行”之间，还有很多工程细节。

3.1 第一象限（优先区）的覆盖策略：深度覆盖 + 人工精审

这类代码的特点：逻辑密度高、边界条件多、测试价值极大。我的标准是：不仅要100%分支覆盖，还要覆盖所有已知的边界条件和异常路径。

实战案例：一个资金分配的算法类

这个类只有150行代码，但包含了一个复杂的“手续费分摊、补贴分摊、实收金额计算”逻辑。它是支付链路中所有人都会调用的“转盘中心”，却没有任何测试。

我的操作流程：

Step 1：让Claude Code充分理解上下文

我不会直接说“给这个类写测试”，而是先提供一个上下文文件：

## 项目上下文 (.claude.md)
项目信息

这是一个互联网金融支付系统

使用Java 11, Spring Boot 2.6, JUnit 5, Mockito

金额字段统一使用BigDecimal，精度为分（小数点后两位，HALF_UP舍入）

手续费计算规则遵循《XX银行代收付业务手续费标准V3.2》

补贴金额必须为非负，且不得超过商户设定上限

测试约定

测试类命名：{原类名}Test，放在相同包路径的test目录下

使用@ExtendWith(MockitoExtension.class)

所有测试方法使用@DisplayName中文描述

禁止使用PowerMock，代码必须支持常规Mockito测试

每个public方法至少覆盖：正常路径、null参数、空集合、边界值、异常抛出

Step 2：使用明确的Prompt生成测试

为以下类生成完整的JUnit 5单元测试：
【类路径】com.xxx.payment.core.FeeAllocationCalculator

【要求】

完整覆盖 feeAllocate() 方法的所有分支

所有金额边界：0.00元、0.01元、9999999.99元

手续费为零、手续费超过本金、手续费恰好等于某个分摊金额

补贴池空、补贴恰好用完、补贴有剩余

商户未配置补贴上限

所有测试必须使用真实计算逻辑（Mock只用于外部依赖，但本类无外部依赖，应该直接测试真实计算）

输出测试代码，并在代码后附上一个“未覆盖的边界条件”列表，列出你认为可能遗漏的场景

<p><strong>Step 3：人工审查，我有三个“必查项”</strong></p>

每次Claude Code生成测试后，我不会全量细读每一行。但我一定会检查三个东西：

1. 断言对象是否正确？ 测试的是result.getMerchantAmount()，而不是一个永远不会变的固定值。Claude Code偶尔会生成“为通过而通过”的断言。
2. 边界值是否足够极端？ 比如0.00元和null，AI经常只覆盖null，遗漏0.00（在金融系统中，0.00和null的含义完全不同）。
3. 异常场景是否真实？ AI有时会生成一个“必然抛异常”的测试，但方式是构造了一个违反Java语法必报错的数据，而不是模拟真实的异常场景。这种测试一文不值。

我一共让Claude Code生成了4轮测试。第一轮覆盖率87%，遗漏了“多商户分摊时某商户手续费恰好为0”的场景；第二轮补上了，但断言错了；第三轮断言对了，但遗漏了“补贴金额超过商户分摊金额”的非法状态；第四轮才达到我能接受的标准。

这个案例告诉我们：Claude Code在理解复杂业务规则上有其天花板，它在“逻辑补全”上很强，但在“发现逻辑漏洞”上很弱。而恰好后者才是测试的核心价值。

3.2 第二象限（重构先行区）的覆盖策略：解耦-隔离-测试

这是整个策略中最难、也最体现工程能力的部分。

核心判断：不要在有问题的结构上硬写测试

我踩过这个坑。那是一个2000行的PaymentServiceImpl，里面十几层if-else嵌套，依赖了支付通道适配器、风控SDK、短信网关、账户RPC。我一开始直接让Claude Code为它生成测试，结果生成的测试文件3500行，80%都是Mock的when-thenReturn语句，而真正验证业务逻辑的断言不到200行。

更致命的是，这些测试几乎不可维护：只要有人改动了一个if条件，30个测试同时挂掉。

正确的打法：先做“外科手术式”小重构

以这个PaymentServiceImpl为例，我的策略是：

Step 1：识别“可提取的纯函数”

在这个2000行的类中，有三段代码是可以直接提取的，因为它们不依赖任何实例状态，只依赖输入参数：

• 支付金额的校验逻辑（120行）：校验金额范围、币种匹配、优惠券后金额合法性
• 扣款渠道的排序逻辑（80行）：根据费率、成功率、余额状态排序可用通道
• 交易流水号生成（45行）：按特定规则拼接业务标识和序列号

Claude Code可以帮助识别这些代码。我用的Prompt是：

分析PaymentServiceImpl.java，列出所有不依赖实例字段（this.field）的方法或代码块。
这些代码只使用局部变量、方法参数、静态常量。输出每个块的起止行号和简要功能描述。

Step 2：将纯函数提取到独立类

我将这三个逻辑提取到了三个独立的类：PaymentAmountValidator、ChannelRanker、TransactionIdGenerator。每个类都有清晰的输入输出，没有隐式依赖。

这一步，Claude Code可以执行，但你必须Review。 AI倾向于提取得过于碎片化，它可能会把3行代码也提取成一个类，导致过度设计。我的经验是：只提取那些至少有2个以上测试场景、且逻辑独立到可以用一句话清晰描述功能的代码块。

Step 3：为提取后的新旧代码分别覆盖测试

重构完成之后，测试路径就清晰了：

• 对于提取出来的独立逻辑类，它们现在属于第一象限，直接按3.1的策略覆盖。
• 对于重构后的原Service（现在变薄了，主要做流程编排），测试策略变为：Mock所有依赖，验证编排逻辑是否正确调用了各个子模块，以及异常路径下的回滚行为。

一个关键红线： 在提取逻辑时，不要改变原有代码的行为。这要求你在提取前后，对同一组输入，输出必须完全一致。如果原逻辑有Bug呢？记录它，但不要在这次修复。 修复Bug和添加测试，是两件不同的事，混在一起做会让你无法区分“测试失败”是因为提取错误还是因为Bug被暴露。这是我的血泪教训。

3.3 第三象限（效率区）的覆盖策略：批量生成 + 抽样审查

这类代码是Claude Code最擅长、也是最唬人的领地。DTO转换器、日期格式化工具、简单的getter/setter模式代码，Claude Code可以在几秒内生成干净的测试。

但正因为“干净”，很多工程师会放松警惕，看一眼100%覆盖率，点了Commit。

我的吃亏经历

我们有一个OrderDTOConverter，1200行，全是A.setXxx(B.getXxx())和少量的枚举转换。Claude Code生成了完美的测试，覆盖率100%。

两个月后，线上出现了一个Bug：用户在页面上看到的价格，和实际扣款价格不一致。排查发现，OrderDTOConverter中有一行：

target.setDisplayPrice(source.getActualPrice().multiply(new BigDecimal("1.13")));
它在将“实收金额”转换为“展示价格”时，硬编码了1.13的税率系数。Claude Code生成的测试忠实地验证了“乘以1.13后等于目标值”，但它没有发现这个系数在2023年税改后应该是1.09。

抽样审查策略

对于第三象限的批量生成，我不做全量审查（那会回到人手写测试的老路上），但我执行以下抽样规则：

随机抽取10%的测试，人肉阅读断言

重点查看所有涉及数字运算、字符串拼接、时区转换、枚举映射的测试

如果10%中发现2个或以上问题，则100%重新审查该批次

这个采样策略在我项目中发现了3个隐藏问题：一个时区转换Bug（UTC+8写成UTC+0）、一个精度丢失（BigDecimal构造函数用了double）、一个枚举默认值处理不当。

这些Bug不是AI生成的测试引入的，而是AI生成的测试没有发现原有Bug。 区别在于：前者是AI犯错，后者是AI太“蠢”，它只会检查代码做了什么，而不会检查代码该不该这么做。

4 第四象限（观察区）的覆盖策略：不做单元测试，改为集成监控
对于第四象限的代码（低业务影响 + 低可测试性），我的判断是：不值得为它们写单元测试。 但这不是放弃。我把测试策略改为：

针对这些模块的关键输出点，设置集成测试或端到端测试，只验证“最终结果符合预期”

在生产环境设置业务监控告警，如果这些低价值模块的输出偏离基线（比如旧报表生成失败率突然从0.1%升到5%），自动告警

一个务实的判断： 第四象限的很多代码是“历史上重要但现在边缘”的逻辑。它们可能在某次大重构中被彻底删除，也可能在未来两年无人触碰。花时间为它们写单元测试，是对工程资源的浪费。




第三步：高质量Prompt的工程化方法，让Claude Code理解你的项目“宪法”
如果说分级策略是“做什么”，那这一章讲的是“怎么做”。我所见过的Claude Code测试生成失败案例，80%的原因都可以追溯到Prompt不够精确。

1 写在.claude.md里的，不是配置，是你的项目宪法
Claude Code支持一个.claude.md文件，它会在每次对话时被自动加载作为上下文。大多数人的.claude.md是项目简介，而我的，是一份测试规范宪法。

一份好用的.claude.md应该包含什么

基于我反复试错后的沉淀，至少包含这些章节：

项目技术栈声明（精确到版本）

Java 11 (Amazon Corretto)

Spring Boot 2.6.3

JUnit 5.8.2 (不要使用JUnit 4注解)

Mockito 4.5.1 (优先使用mockito-inline以支持final类mock)

AssertJ 3.22.0 (用于复杂对象断言)

版本很重要。如果我写“Spring Boot 2.x”，Claude Code可能生成Spring Boot 3的API调用风格，导致编译失败。版本精确到小版本号，能大幅减少这类“AI幻觉”。

2. 测试风格约定

- 类名: {TargetClass}Test
方法名: 无要求，使用@DisplayName中文描述

Mock方式: 接口使用@Mock，实现类使用mock(Class)方法

禁止: 不使用@InjectMocks（容易隐藏依赖缺失问题），不使用PowerMock

断言风格: 优先使用AssertJ的assertThat(...).isEqualTo(...)，比JUnit自带的更清晰

3. “红牌”规则（绝对不可以做的）

这是我在多次踩坑后提炼的，Claude Code如果不被告知，会“下意识”生成一些看似无害但实际危险的测试代码：

【红牌规则】以下情况，测试即使通过也必须标记为FAIL:
测试中使用了Thread.sleep() ， 用Awaitility替代

测试依赖了方法的执行顺序 ， 每个test必须独立

测试中出现了ReflectionTestUtils.setField() ， 说明设计有问题，应通过构造器注入解决

测试对BigDecimal使用了equals() ， 必须使用compareTo()

测试中对时间进行了new Date() ， 必须通过Clock注入控制时间

测试访问了真实的文件系统、网络、数据库 ， 必须Mock

这些规则不是想出来的，是痛出来的。比如BigDecimal.equals()，它在比较1.00和1.0时会返回false，如果你没吃过这个亏，你可能永远意识不到AI生成的测试有这个问题。

4. 业务领域特定规则

这是通用教程大概率不会涉及的最大差异性内容：

【金融业务特定规则】
所有金额计算必须使用BigDecimal(String)构造，禁止使用BigDecimal(double)

除法运算必须指定RoundingMode和scale

费用计算必须从内到外逐层执行（手续费 ÷ 通道 → 税费 ÷ 通道 → 补贴分配 → 最终结算）

分账计算结果不能包含负数金额

支付渠道降级顺序固定为：A银行 > B支付 > C钱包（不可调整，有合同约束）

这些业务规则告诉Claude Code：你不是在测一个普通的Java类，你是在测一套有严格金融规范的系统。 我发现，当.claude.md包含这类规则后，Claude Code生成的测试中，关于金额精度、舍入方向、负数校验的边界条件，质量提升了不止一个档次。

4.2 Prompt的“结构化递进”技巧

直接说“给这个类写测试”和用以下结构化的递进Prompt，生成的测试质量差距明显。这是我验证过的模板：

【任务】为 [类名.java] 生成JUnit 5单元测试。
【阶段1 - 先分析，不要写测试】

请先阅读目标类的代码，输出：

该类的所有public方法列表及作用（一句话描述）

如果让你为这个类写测试，你觉得最难测的是哪个方法？为什么？

列出所有你需要Mock的外部依赖（包括静态方法调用、System.currentTimeMillis()、文件IO等）

识别所有存在潜在测试盲区的逻辑（如private方法中的复杂条件、没有覆盖的catch块）

【阶段2 - 基于你的分析，开始生成测试】

测试类放在 src/test/java/同包名/ 目录下

遵循 .claude.md 中的全部规则

对于阶段1识别的“测试盲区”，使用反射或包级可见性的Test Helper方式覆盖

生成完成后，在测试代码末尾以注释形式列出“认为可能存在但未覆盖的边界条件”以及原因

这个分阶段Prompt的价值在于：它让Claude Code先在“分析”模式下建立对代码的理解，再切换到“生成”模式。 这避免了AI一上来就写测试，写到一半才发现对一个核心方法的理解有误。

在我的项目中，使用这个递进Prompt后，首次生成的测试可用率从约40%提升到了约70%，减少了接近一半的迭代轮次。

4.3 一个被我多次复用的“Mock数据工厂”思路

在测试包含复杂领域对象的Service时，构造测试数据是最大的体力活。一个支付订单可能有30个字段，其中20个必填、5个有关联校验，手写数据工厂能写到崩溃。

但Claude Code可以帮你生成数据工厂，只要你给出正确的指令。

为 com.xxx.payment.domain.PaymentOrder 的所有字段生成一个测试数据工厂类PaymentOrderTestDataFactory，
要求：

生成一个静态方法 createValidOrder()，返回一个所有必填字段合法的订单（可用于Happy Path测试）

生成一个静态方法 createOrderWithNullField(PaymentOrderField field)，

根据传入的字段枚举，返回该字段为null、其他正常（用于null校验异常测试）

所有金额字段使用BigDecimal("100.00")作为默认合法值

所有时间字段使用LocalDateTime.of(2024, 1, 1, 12, 0)作为默认值

生成JavaDoc注释，标注每个字段的业务含义和合法取值范围

<p>这个工厂类<strong>不是你手写的，但每个字段的值是你指定的。</strong> 这就保证了生成的测试数据既符合业务规范，又不会因为AI随意编造数据而产生“巧合通过”的测试。之后写任何测试，直接<code class="article-inline-code">PaymentOrderTestDataFactory.createValidOrder()</code>作为起点，效率提升明显。</p>

五、第四步：质量验证，覆盖率数字不等于安全感

当Claude Code为你生成了成百上千的测试，覆盖率报表上一片绿色时，很容易产生一种错觉：系统安全了。

这部分我犯过最大的错，就是把覆盖率数字当成了安全感的来源。以下是我建立的质量验证框架。

5.1 覆盖率陷阱：100%覆盖率不等于Bug无处遁形

在我项目的某次Code Review中，我看到这样一个测试：

@Test
@DisplayName("测试金额计算")

void testCalculateFee() {

BigDecimal result = feeCalculator.calculate(new BigDecimal("100.00"));

assertNotNull(result);

// 覆盖率100%

}

这个测试通过了，覆盖率工具也显示该行被覆盖。但它验证了什么？它只验证了方法没有抛NPE。 100.00元的手续费是多少？应该是2.00元、还是3.50元？不知道。这就是我称之为“伪测试”的东西：它只覆盖了代码行，没有覆盖业务含义。

识别伪测试的三个特征：

1. 断言太宽泛： assertNotNull()、assertTrue()、assertThat(list).isNotEmpty()，这些断言几乎永远为真。
2. 没有验证核心输出值： 测了一个计算方法，却没有断言计算结果的具体数值，更没有覆盖多个输入场景。
3. 出现了verifyNoMoreInteractions()却没有对应验证期望行为：这通常意味着测试者只想让测试通过，但并不关心Mock是否被正确调用。

5.2 变异测试：用“突变”验证测试的真实有效性

我引入了一个自检环节：在生成的测试全部通过后，手动对业务代码引入一个明显的Bug，看测试是否能抓住它。

这种操作学名叫变异测试，工具上可以用Pitest之类的自动变异工具。但我在这个项目中用的是更“土”但更直接的方法：

针对每个高优先级模块，我会手动修改三个地方：

• 修改一处关键计算（比如把加法改成减法）
• 删除一行校验逻辑（比如去掉if (amount == null) throw ...）
• 反转一个条件（把>改成>=）

然后重新运行测试。如果测试全绿，说明这些测试根本不可靠。 只有当一个以上的测试变红时，这批测试才有真正的Bug发现能力。

我在12个高优先级模块的产品线中共手动引入了36个Bug，结果如下：

有两个Bug没有被任何测试发现。 一个是关于“闰年2月29日的手续费计算”时区偏移问题，一个是“金额恰为0.005时舍入方向与银行规则不一致”。这两个场景都是我们在边界条件梳理时遗漏的，而Claude Code也没有“想到”。

这说明：AI + 人工 ≠ 完美。但AI能覆盖你肯定会遗漏的大多数场景，而人需要专注于AI更可能遗漏的极端业务场景。

5.3 测试的可维护性审查：一个被严重低估的维度

测试代码也是代码，也需要维护。而且，糟糕的测试代码比没有测试更可怕，它给你虚假的信心，同时阻碍重构。

我在项目中建立了一套测试可维护性的审查清单，Claude Code生成的测试必须通过以下检查：

一个令我印象深刻的例子： 我曾审查过一个Claude Code生成的测试，它Mock了整个RedisTemplate，when-thenReturn写了12行，而测试最后只断言了assertThat(result).isNotNull()。我追查后发现，这12行Mock中有7行对应的逻辑在当前代码路径中根本不会执行。这就是典型的“为了让测试通过而堆砌Mock”，它成功运行了，但毫无意义。

我让Claude Code重构了这个测试，Prompt是：

请移除该测试中所有“当前测试场景不会走到”的Mock代码。
只保留当前测试路径真正需要的Mock。

如果移除后发现某个Mock是路径必备的，请在注释中说明“为什么需要这个Mock”。

重构后，这个测试从84行缩减到了29行，可读性提升了好几个级别。

六、第五步：CI/CD集成，让覆盖策略成为日常，而非一次性运动

如果你只是在项目某个阶段突击补测试，两个月后，覆盖率又会掉回去。原因很简单：新增的代码没有测试，旧的测试因业务变化而失效，没人维护。

我在项目中建立了以下机制，让基于Claude Code的测试覆盖成为持续过程。

6.1 与代码变更关联的增量覆盖策略

核心原则：任何PR（Pull Request）中，新增或修改的代码行必须有对应的测试覆盖，覆盖层级取决于该代码所处的象限。

具体执行方式：

1. 当一个开发者提交PR时，CI会自动运行git diff main…feature-branch来确定变更范围
2. 变更的每个文件，根据其归属象限，CI会检查对应的覆盖率阈值：

• 第一象限文件：新增/修改代码的行覆盖率≥95%
• 第二象限文件：≥90%（但允许如果该文件在“重构计划中”则标记为warning而非block）
• 第三象限文件：≥80%
• 第四象限文件：≥50%或不做要求（根据团队共识）

如果未达标，CI会在PR评论中自动建议：请使用Claude Code为这些文件生成测试

Claude Code在这个流程中不是一个手动工具，而是一个可被调用的自动化环节：

# 在CI中集成Claude Code的示意脚本
for file in $(git diff origin/main --name-only | grep '\.java$'); do

if ! coverageCheck $file ${threshold}; then

claude --print "为文件 $file 生成JUnit 5测试用例，覆盖所有新增/修改行，遵循.claude.md规范"

fi

done

这里的关键设计是：不是所有未覆盖代码都自动生成测试，而是只针对“本次变更”涉及的代码。 这避免了Claude Code对全量代码批量操作带来的审查负担，同时确保每次改动都有安全网。

6.2 测试失效的自动感知与修复建议

遗留系统维护中最常见的问题：改了A服务的接口签名，B服务的Mock失效了，但直到手动跑全量测试才被发现。

我的解决方案：

1. 每天凌晨在CI中执行一次全量测试（包括Claude Code生成的和人手写的）
2. 如果某个测试连续3天失败，CI自动创建一个Ticket，并在Ticket中调用Claude Code分析失败原因

Claude Code的分析Prompt如下：

以下测试持续失败，请分析原因并提出修复建议：
【测试代码】

{粘贴测试代码}

【目标方法当前代码】

{粘贴最新的业务代码}

【失败信息】

{粘贴JUnit失败输出}

请判断：

是业务代码的预期行为改变导致测试失效？（如果是，需要更新测试）

是业务代码引入了Bug导致测试正确失败？（如果是，需要修复业务代码）

是外部依赖或配置变化导致？（如果是，需要更新Mock）

输出修复建议和应该修改的代码。

这个机制的价值在于：它把“测试腐烂”从隐性风险变成了显性通知。 你不会在发布前一天才发现测试全红，而是每天都知道哪些测试需要更新，而且Claude Code给出了修复建议，开发者只需要审核和执行。

6.3 一张“测试资产”的实时热力图

我让团队搭建了一个简单的看板页面，展示每个微服务的测试状态。这面看板体现了我们工作的“温度”：

• 绿色（健康）： 覆盖率≥90%，最近7天无失败，测试代码审查通过
• 黄色（关注）： 覆盖率70%-90%，或有偶发失败
• 红色（欠债）： 覆盖率<70%，或有持续失败未修复

这个看板最核心的指标不是覆盖率，而是“近7天因测试发现而拦截的线上Bug数”。 当这个数字持续为0时，不是说明系统完美，而是说明测试可能已经形同虚设，要么是测试太弱抓不住Bug，要么是根本没有覆盖高风险变更。

在我离开项目时，这个看板上的数据显示：近7天拦截Bug数3个，近30天拦截Bug数11个。这些Bug如果没有测试，都会流入生产环境。每次我看到这个数字，就觉得那三个月的投入是值得的。

七、你的行动路线图：第一周的五个关键决策

如果你现在就要用Claude Code为一个遗留项目补测试，以下是我建议的第一周行动路径。注意：不要跳过顺序，每一步的输出是下一步的输入。

第1天：建立分级地图（4-6小时）

输入： 项目代码库

产出： 四象限分级表格（至少覆盖80%的文件）

• 上午：用Claude Code扫描所有模块，生成调用关系报告和复杂度报告
• 下午：和团队最熟悉业务的人一起标注“业务影响度”
• 晚上：自己过一遍标注结果，标注“可测试性”

风险： 业务影响度标注不准。应对：如果实在找不到熟悉的人，优先把“包含金额计算、权限校验、外部接口调用的类”标记为高影响。

第2天：写.claude.md宪法文件（2-3小时）

输入： 你的技术栈、团队编码规范、业务领域知识

产出： 一份包含技术栈声明、测试风格约定、红牌规则、业务特定规则的.claude.md

• 对照4.1节的模板，逐一填写
• 业务规则部分可能不完整，没关系，先写你确认的，后续遇到再补充

风险： 红牌规则遗漏。应对：参考4.1节的红牌清单作为起点，每次遇到意想不到的测试问题时，补充一条红牌规则。

第3天：选一个第一象限模块做端到端试点（4小时）

输入： 分级地图中标记为“第一象限”的一个中等大小（100-300行）的模块

产出： 一个经过完整“生成-审查-迭代”周期的测试文件

• 严格按照3.1节的流程执行
• 记录你在审查中发现了哪些问题、迭代了几轮、每轮Prompt做了哪些调整
• 不要追求完美，完成比完美重要

风险： 第一个模块选得太复杂，导致挫败感。应对：选一个纯计算类，不涉及任何外部依赖的。即使是StringUtil也可以，重点是走通流程。

第4天：处理最难的第二象限模块（6-8小时）

输入： 分级地图中标记为“第二象限”的一个高影响模块

产出： 重构计划 + 提取的独立纯函数 + 为重构后代码生成的测试

• 今天可能是最难的一天。你可能会发现某些代码的耦合超乎想象
• 如果重构的阻力太大（比如涉及太多上下游依赖），不要硬刚，退回到集成测试策略，并标记这个模块为“需要专项重构”的Tech Debt
• 成功的标准是：你至少提取出了一段纯逻辑，并为它写了测试

风险： 重构引入回归Bug。应对：先跑通现有的任何测试（如果有），重构过程中频繁编译，小步提交。

第5天：建立CI门槛（2小时）+ 批量处理第三象限（剩下的时间）

输入： 前三天的产物

产出： CI集成的增量覆盖检查 + 第三象限大批量测试生成

• 上午：按照6.1节的思路配置CI，只针对第一和第二象限设置强制门槛，第三和第四象限设建议门槛
• 下午：用Claude Code批量处理第三象限，采用3.3节的“抽样审查”策略
• 不要试图一天覆盖所有第三象限，选一个服务先跑通

第一周结束时你应该拥有的：

• 一份覆盖了项目80%以上模块的四象限分级表
• 一份可以复用的.claude.md宪法文件
• 一个第一象限模块的完整测试（你知道高质量=什么标准）
• 一个第二象限模块的重构+测试（你知道难点在哪）
• CI中运行着的增量覆盖检查（新代码必须带测试）
• 开始批量生成的第三象限测试（覆盖率数字在往上走）

八、八个我在执行中反复提醒自己的原则

这些原则不是从书本上学来的，是我在凌晨三点调试测试失败、在Code Review中争论覆盖策略、在线上事故复盘时被CTO灵魂拷问后，刻在脑子里的。

原则一：测试覆盖率是滞后指标，真正的指标是“测试对Bug的拦截率”。

如果你这个季度写了1000个测试，但线上Bug数和上季度一样，你的测试策略可能有问题。追求覆盖率数字容易，追求真正的Bug发现能力难。

原则二：AI生成的测试必须经过人工审查，审查的标准是“如果这个测试失败了，我能立刻知道哪里出问题了吗？”

如果一个测试失败信息是expected: <true> but was: <false>，且没有更多的上下文，这个测试就不合格。

原则三：不要在有问题的结构上硬写测试。先做最小重构。

你欠了技术债，现在是还债的时候。用AI给糟糕的设计打补丁，只是延缓了灾难。

原则四：不是所有代码值得测试。第四象限的代码，让它们安静地运行，用监控而非测试来兜底。

你的精力是有限的，把它花在影响最大的20%代码上，而不是均匀撒在100%代码上。

原则五：Claude Code擅长“逻辑补全”，不擅长“逻辑质疑”。

它可以写出一个方法的所有可能路径的测试，但它不会质疑这个方法的设计是否合理。质疑是人的任务。

原则六：每一次线上Bug，都是测试策略的反馈信号。问一问：为什么这个Bug没被拦住？是优先级没排到？还是测试不够严？还是压根没有被覆盖？

然后更新你的分级地图、红牌规则、Claude Code的Prompt模板。

原则七：测试代码也是代码，需要维护。允许低质量的测试积累，等于在代码库中埋地雷。

如果某个Claude Code生成的测试让你感觉“为了有而有”，删掉它，或者重写它。宁可少而精。

原则八：工具是放大器，它放大你的判断力，也放大你的错误。

如果你不知道好的测试长什么样，Claude Code只会加速产出坏的测试。在熟练使用工具之前，先建立你对“好测试”的判断力。

九、结语：向后看，向前走

写这篇文章时，距离我接手那个支付系统已经过去了一年多。现在它的测试覆盖率稳定在78%左右，最核心的模块在95%以上。

但比数字更重要的是团队的变化。以前提测时大家会心虚，现在CI跑完绿灯，大家有一种踏实的疲惫，疲惫是因为确实要写测试，踏实是因为有人帮你兜底。

Claude Code在这个过程中扮演了催化剂角色。它把“写测试”这个原本需要强大意志力才能启动的事情，变成了一个可以快速开始、逐步迭代的工程过程。但它不是银弹。它不能替你理解你的业务，不能替你判断风险优先级，不能替你承担线上事故的责任。

你的专业判断力，才是这个覆盖策略中最不可替代的部分。

如果你想开始，我的建议是：不要想着“我要把整个项目的测试补完”。选择一个你明天要改动的高风险模块，按照这篇文章的流程走一遍。完成一个模块的完整覆盖，比粗糙地扫过十个模块有价值得多。

然后，当第一个Bug被你的测试拦截在PR阶段时，你会知道这一切都是值得的。