Lombok 生成的 getter、setter、构造器等代码无需手动编写单元测试；应将测试焦点放在业务逻辑上，并通过配置代码覆盖率工具排除 Lombok 生成的字节码，以获得真实、有意义的覆盖率指标。
如何为 lombok 注解编写单元测试：正确理解测试边界与覆盖率策略
Lombok 的核心价值在于消除模板代码（boilerplate），而非引入新的可测试行为。@Data、@NoArgsConstructor、@AllArgsConstructor 等注解在编译期由 lombok-agent 或 annotation processor 自动生成字段访问器、构造方法和 toString()/equals()/hashCode() 实现——这些是经过充分验证的稳定基础设施，其正确性由 Lombok 官方团队负责保障（正如你不会为 javac 编译出的字节码或 Hibernate 的代理机制单独写测试一样）。
因此，对如下类：
@Data
@NoArgsConstructor
@AllArgsConstructor
public class ABC {
private String status;
private String errorCode;
private String message;
private String id;
private Long orderNumber;
private Long lineId;
}
✅ 应当测试的：该类在业务上下文中的使用逻辑，例如：
- 作为 DTO 被 Controller 接收并校验；
- 在 Service 层参与计算或状态转换；
- 与数据库实体映射时的字段一致性（配合 @Entity 或 @Mapper）；
- 自定义 equals() 行为是否符合业务语义（若重写了 equals/hashCode，则需测试）。
❌ 不应当测试的：Lombok 自动生成的 setStatus()、getStatus()、全参构造器等——它们不是你的业务契约，而是工具链产物。
⚠️ 注意事项：
- 若强制为 Lombok 方法编写测试（如您示例中 testupdate_1），不仅冗余低效，还会导致虚假高覆盖率（覆盖了非业务代码），掩盖真正未测的业务路径；
- 主流覆盖率工具（JaCoCo、Clover）均支持按源码路径或类名排除规则。推荐在 pom.xml 中配置 JaCoCo 忽略 Lombok 类：
<plugin><groupid>org.jacoco</groupid><artifactid>jacoco-maven-plugin</artifactid><configuration><excludes><exclude>**/lombok/**</exclude><exclude>**/*$AjcClosure*</exclude><!-- 排除 Lombok 生成的桥接方法、合成方法 --><exclude>**/*$$EnhancerBySpringCGLIB$$*</exclude></excludes></configuration></plugin>- 使用 IDE（如 IntelliJ）或构建工具检查反编译后的 .class 文件，确认 ABC 类确实包含 setStatus 等方法——这证明 Lombok 已生效，无需再为其“验证存在性”。
总结：测试的目标是保障业务行为正确，而非验证框架是否工作。将测试资源聚焦于 ABC 如何被使用（例如：OrderService.updateStatus(ABC) 是否触发预期状态流转），而非 ABC.setStatus("OK") 是否赋值成功。合理配置覆盖率排除规则后，您的测试报告将真实反映业务代码的健壮性，而非被 Lombok 的“影子代码”干扰。
