Java测试用例自动生成实战：从Mock到断言的全流程优化

2次阅读

没有评论

共计 1933 个字符，预计需要花费 5 分钟才能阅读完成。

每次手动编写测试用例时，我总在重复做三件痛苦的事：

为相似功能编写雷同的测试模板代码
绞尽脑汁设想各种边界条件
不断调整断言语句来匹配业务逻辑变更

更可怕的是，当项目迭代三个月后回头看测试代码，会发现覆盖率就像破洞的渔网——明明测过却处处漏风。这正是自动化测试用例生成要解决的痛点。

优势：
原生支持参数化测试（@ParameterizedTest）
Mockito 的 BDD 风格更符合人类思维
社区活跃度最高（GitHub 12k+ stars）
短板：
无法 Mock 静态方法（需配合 PowerMock）
测试生命周期管理较复杂

杀手锏 ：
强大的依赖注入能力
可以 Mock 静态块和构造函数
自带并行测试执行器
代价：
学习曲线陡峭
运行时字节码操作影响性能

经过实际项目验证，我推荐中小项目选择 JUnit5+Mockito 组合，它的轻量化和可读性更适合快速迭代。

// 创建测试类模板
TypeSpec.Builder testClass = TypeSpec.classBuilder("UserServiceTest")
    .addModifiers(Modifier.PUBLIC)
    .addAnnotation(SpringBootTest.class);

// 添加 Mock 对象字段
testClass.addField(FieldSpec.builder(UserRepository.class, "userRepo")
    .addAnnotation(Mock.class)
    .build());

// 注入被测对象
testClass.addField(FieldSpec.builder(UserService.class, "userService")
    .addAnnotation(InjectMocks.class)
    .build());

通过解析方法参数类型，自动生成极端测试数据：

对 String 类型生成：null、””、超长字符串
对数值类型生成：0、Integer.MAX_VALUE、负数
对集合类型生成：空集合、null 元素集合

List<Object[]> generateEdgeCases(Method method) {return Arrays.stream(method.getParameters())
        .map(param -> {Class<?> type = param.getType();
            if (type == String.class) {return new Object[]{null, "","a".repeat(1000)};
            }
            // 其他类型处理...
        }).collect(Collectors.toList());
}

根据返回类型自动匹配断言方式：

对象：使用 AssertJ 的 fluent 断言
集合：验证 size 和包含关系
异常：断言特定异常类型

String generateAssertion(TypeName returnType) {if (returnType.equals(ClassName.get(List.class))) {return "assertThat(result).hasSizeGreaterThan(0)";
    }
    // 其他类型断言生成逻辑...
}

我曾经在生成用户注册测试时，由于未设置过滤规则，产生了 200+ 个无效用例。建议：

对工具类方法限制生成数量
对 DTO 对象忽略 setter/getter 测试
设置最大生成深度防止递归爆炸

遇到第三方 final 类时，可以：

使用 Wrapper 模式包裹目标类
配置 MockMaker 扩展（需要 -javaagent）
改用集成测试替代单元测试

# GitLab CI 示例
test:
  stage: test
  script:
    - mvn test-compile
    - java -jar test-generator.jar --target=com.example.service
    - mvn surefire:test -Dtest=AutoGenerated*Test
  artifacts:
    paths:
      - target/site/jacoco/ # 收集覆盖率报告

当测试生成遇到 TDD 时，可以尝试：