lombok 生成的 getter、setter、构造器等代码无需手动编写单元测试；应通过排除 lombok 生成代码来提升覆盖率统计准确性，并聚焦于业务逻辑的真实验证。
lombok 生成的 getter、setter、构造器等代码无需手动编写单元测试；应通过排除 lombok 生成代码来提升覆盖率统计准确性，并聚焦于业务逻辑的真实验证。
Lombok 的核心价值在于消除样板代码（boilerplate），而非引入新的可测行为。当你在类上添加 @Data、@NoArgsConstructor 或 @AllArgsConstructor 等注解时，Lombok 在编译期自动生成字段访问器、构造方法和 toString()/equals()/hashCode() 等方法——这些是编译器插件行为，其正确性由 Lombok 官方团队负责保障与测试，正如你不会为 javac 编译出的字节码结构或 switch 语句的语义写测试一样。
因此，对如下类：
@Data
@NoArgsConstructor
@AllArgsConstructor
public class ABC {
private String status;
private String errorCode;
private String message;
private String id;
private Long orderNumber;
private Long lineId;
}
✅ 推荐做法是：不为 Lombok 自动生成的方法编写测试用例
❌ 不应编写类似 testupdate_1() 这样仅调用 setter/getter 并断言默认值的测试——它既不验证业务逻辑，也无法提升软件质量，反而稀释测试维护成本与信号噪声比。
? 正确提升代码覆盖率的方案：配置覆盖率工具忽略 Lombok 生成代码
以主流工具为例：
-
JaCoCo（Maven）：在 pom.xml 中添加 excludes 规则：
<plugin><groupid>org.jacoco</groupid><artifactid>jacoco-maven-plugin</artifactid><version>0.8.12</version><configuration><excludes><exclude>**/*$AjcClosure*.class</exclude><exclude>**/lombok/**</exclude><exclude>**/*Lombok*.class</exclude><!-- 排除所有 Lombok 增强类（关键） --><exclude>**/*$*.*</exclude></excludes></configuration></plugin>
IntelliJ IDEA / Gradle + JaCoCo：可在 jacocoTestReport 任务中配置 classDirectories 过滤，或使用 @Generated 注解配合 @Generated("lombok")（需启用 lombok.addLombokGeneratedAnnotation = true）并让 JaCoCo 忽略 @Generated 标记的类。
? 何时才需要“测试 Lombok 类”？
仅当该类参与有意义的业务交互时，才需测试其行为，例如：
- 测试 equals() 和 hashCode() 是否满足业务一致性（如用于 HashSet 去重）；
- 测试 @Builder 构建的对象是否符合不变式；
- 测试 @ToString(exclude = "password") 是否真正脱敏；
- 验证 @RequiredArgsConstructor 下的不可空字段注入是否触发预期异常。
示例（验证 equals 行为）：
@Test
void testEqualsAndHashCode() {
ABC a = new ABC("OK", "ERR001", "Success", "id-1", 100L, 1L);
ABC b = new ABC("OK", "ERR001", "Success", "id-1", 100L, 1L);
assertEquals(a, b);
assertEquals(a.hashCode(), b.hashCode());
}
? 总结建议：
- ✅ 将测试资源聚焦于：业务逻辑、边界条件、异常流、集成行为；
- ✅ 配置覆盖率工具跳过 Lombok 生成代码（非源码行），使覆盖率真实反映你的代码质量；
- ✅ 如需验证 Lombok 行为（如 @Builder.Default、@Singular），优先使用编译期检查（如启用 lombok.anyConstructor.addConstructorProperties = true）或小范围契约测试；
- ❌ 避免“为覆盖而覆盖”，尤其不要为 setXxx()/getXxx() 编写无业务语义的测试——这违背测试驱动开发（TDD）初衷，也损害长期可维护性。
