我终于停止写 JUnit 了！用 JavaParser + GPT-4 自动生成 90% 覆盖率的单元测试-编程阁

🛑 前言：谁真心喜欢写单元测试？

说句心里话，写业务代码是“创造”，写单元测试是“折磨”。

繁琐：为了测一个if-else，要 Mock 一堆依赖。
无聊：大部分测试代码都是样板代码（Setup, Mock, Assert）。
硬指标：公司要求覆盖率 80%，否则不让上线。于是大家开始写assert(true)这种自欺欺人的代码。

我尝试过 Github Copilot，它很强，但它不知道我的 Project Context，生成的测试经常引用不存在的方法，或者 Mock 不全。

我们需要一种更“懂”代码的自动化方案。
今天，我将带大家用JavaParser (AST 语法树分析)配合GPT-4，构建一个智能单测生成器。它能自动分析你的代码依赖，自动 Mock，自动覆盖边界条件。

🧠 核心原理：为什么只用 GPT 不行？

直接把一个 1000 行的OrderService.java扔给 GPT，它往往会懵圈，或者消耗巨量的 Token。
正确的姿势是：用 AST 提取“骨架”，让 AI 填充“血肉”。

JavaParser 的作用：

识别依赖：自动扫描@Autowired或private final字段，告诉 AI 需要 Mock 哪些类。
提取方法：分析方法签名、入参类型、返回值，甚至简单的分支逻辑。
精简上下文：只把核心逻辑投喂给 AI，剔除无关的 import 和注释。

生成流程图：

🛠️ 实战开发：手搓单测生成器

1. 引入 JavaParser

这是一个极其强大的 Java 源码解析库。

<dependency><groupId>com.github.javaparser</groupId><artifactId>javaparser-symbol-solver-core</artifactId><version>3.25.0</version></dependency>

2. AST 分析：提取类信息

我们需要写一个 Visitor 来遍历源码结构。

publicclassClassInfoVisitorextendsVoidVisitorAdapter<Void>{privateList<String>dependencies=newArrayList<>();privateList<String>methods=newArrayList<>();@Overridepublicvoidvisit(FieldDeclarationfd,Voidarg){// 提取所有需要 Mock 的依赖字段fd.getVariables().forEach(var->{dependencies.add(var.getType()+" "+var.getName());});super.visit(fd,arg);}@Overridepublicvoidvisit(MethodDeclarationmd,Voidarg){// 提取方法源码if(md.isPublic()){methods.add(md.toString());}super.visit(md,arg);}// Getter methods...}

3. 构造 Context-Aware Prompt

这是让 AI 生成高质量代码的关键。我们不能只说“写个测试”，我们要说：

“这是一个基于 Spring Boot 的类。它依赖了UserRepository和EmailService。请使用JUnit 5和Mockito，为以下placeOrder方法编写单元测试，要求覆盖‘库存不足’和‘支付失败’两个分支。”

publicStringgeneratePrompt(StringclassName,List<String>deps,StringtargetMethod){StringBuildersb=newStringBuilder();sb.append("你是一个 Java 测试专家。请为 ").append(className).append(" 编写单元测试。\n");sb.append("【技术栈】：JUnit 5, Mockito\n");sb.append("【依赖组件（需要 Mock）】：\n");deps.forEach(d->sb.append("- ").append(d).append("\n"));sb.append("【待测方法】：\n").append(targetMethod).append("\n");sb.append("【要求】：\n1. 覆盖所有 if-else 分支。\n2. 使用 Assertions.assertEquals 断言。\n3. 只返回 Java 代码。");returnsb.toString();}

4. 调用 GPT-4 生成代码

（代码省略，标准的 HTTP 调用）

💥 效果演示：从 0% 到 90%

假设我们有一个复杂的业务方法：

publicOrderResultcreateOrder(Useruser,Itemitem){if(user.getBalance()<item.getPrice()){returnOrderResult.fail("余额不足");}if(!inventoryService.hasStock(item.getId())){returnOrderResult.fail("无货");}// ... 扣减库存，创建订单 ...returnOrderResult.success();}

工具自动生成的测试代码：

@ExtendWith(MockitoExtension.class)classOrderServiceTest{@MockprivateInventoryServiceinventoryService;// 自动识别并 Mock@InjectMocksprivateOrderServiceorderService;@TestvoidshouldFail_WhenBalanceNotEnough(){Useruser=newUser(100);// 余额 100Itemitem=newItem(200);// 价格 200OrderResultresult=orderService.createOrder(user,item);assertEquals("余额不足",result.getMsg());}@TestvoidshouldFail_WhenNoStock(){Useruser=newUser(300);Itemitem=newItem(200);// 自动生成的 Stubwhen(inventoryService.hasStock(item.getId())).thenReturn(false);OrderResultresult=orderService.createOrder(user,item);assertEquals("无货",result.getMsg());}}

震撼吗？
它不仅 Mock 了依赖，还准确地理解了if逻辑，构造了两个反向测试用例。这比我自己写的都要规范！

🛡️ 局限性与避坑

复杂数据结构：如果方法入参是一个极其复杂的 DTO，嵌套了十层，GPT 构造测试数据时可能会偷懒（填 null）。这时候需要引入EasyRandom来辅助生成数据。
私有方法：默认策略建议只测 Public 方法。如果必须测 Private，需要生成反射调用代码，这会增加 Prompt 复杂度。
Token 成本：不要把整个文件一次性发过去。按方法粒度生成，虽然请求次数多了，但准确率更高，且不容易超长。