Lombok 生成的 getter、setter、构造器等代码无需手动编写测试用例，应通过配置代码覆盖率工具排除这些自动生成的代码，专注测试业务逻辑而非框架行为。
如何为 lombok 注解编写有效的单元测试：lombok 生成的 getter、setter、构造器等代码无需手动编写测试用例，应通过配置代码覆盖率工具排除这些自动生成的代码，专注测试业务逻辑而非框架行为。
Lombok 的核心价值在于消除模板代码（boilerplate），如 @Data 自动生成 getter/setter/toString/equals/hashCode，@NoArgsConstructor 和 @AllArgsConstructor 生成构造方法。这些代码由 Lombok 在编译期注入，其正确性已由 Lombok 官方团队充分验证和测试——正如你不会为 javac 编译出的字节码或 Hibernate 生成的代理类专门写测试一样，测试 Lombok 的实现属于 Lombok 项目自身的职责，而非你的应用层责任。
✅ 正确做法是：
- 聚焦业务逻辑测试：例如，若 ABC 类参与某个服务流程（如状态校验、DTO 转换、API 响应组装），应针对该流程编写集成或单元测试，验证其行为是否符合预期；
- 避免为 Lombok 方法“凑覆盖率”：像 result.setStatus("") → assertEquals("", result.getStatus()) 这类测试仅验证 Lombok 是否工作，既脆弱（易因 Lombok 版本升级失效）又无实际业务价值；
- 配置覆盖率工具跳过 Lombok 代码：主流工具均支持排除规则，例如：
<!-- Maven + JaCoCo 示例：在 pom.xml 中配置 -->
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.12</version>
<configuration>
<excludes>
<exclude>**/lombok/**</exclude>
<exclude>**/*$*</exclude> <!-- 排除 Lombok 生成的桥接方法、合成方法 -->
<exclude>**/ABC.class</exclude> <!-- 或按需排除具体类 -->
</excludes>
</configuration>
</plugin>Gradle（JaCoCo）示例：
jacoco {
excludes = ['**/lombok/**', '**/*$*', '**/ABC.class']
}⚠️ 注意事项：
- 不要依赖 @Data 的 equals()/hashCode() 进行业务关键比较（如缓存键、集合去重），除非显式确认字段语义合理；必要时应手写或使用 @EqualsAndHashCode(onlyExplicitlyIncluded = true) 精确控制。
- 若需验证 Lombok 行为（如调试罕见问题），可通过反编译 .class 文件（如 javap -p ABC.class）确认生成结果，而非运行时测试。
- 使用 @Builder、@Wither 等进阶注解时，测试重点应是其在构建链路中的使用方式是否符合设计契约（例如 ABC.builder().status("OK").build() 是否返回预期对象），而非测试 builder 方法本身。
总结：高代码覆盖率 ≠ 高质量测试。真正的测试价值在于保障业务正确性与可维护性。将测试资源投入边界条件、异常路径、服务交互等真实风险点，而非 Lombok 这类成熟、稳定、经广泛验证的基础设施层——这既是工程效率的最佳实践，也是专业测试思维的体现。
