JUnit测试实体类Getter/Setter代码覆盖问题求助

首先给你明确结论：你写的第二个测试类是合规的，确实能达到100%代码覆盖，不过我们可以把它优化得更有实际测试价值，同时帮你理清第一个测试报错的根本原因。

为什么第一个测试会报错？ #

你第一个测试犯了Mockito的典型误用：@InjectMocks在这里创建的是真实的AnagrafeUser实例，而非Mock对象。Mockito的when()方法只能用于拦截Mock/Spy对象的方法调用，直接对真实对象调用when(anagrafeUser.getFirstName())自然会报错——Mockito没法拦截真实对象的原生方法执行逻辑。

第二个测试的合理性与优化方向 #

你的第二个测试通过在setUp()里调用Setter，在测试方法里调用Getter并验证非空，确实覆盖了所有Getter和Setter的代码路径，完全符合客户的覆盖要求。不过只验证assertNotNull有点单薄，我们可以优化成验证赋值的正确性，让测试不仅凑覆盖，还能起到实际校验逻辑的作用：

public class AnagrafeUserTest {
    private AnagrafeUser anagrafeUser;

    @Before
    public void setUp() {
        // 实体类无外部依赖，直接实例化即可，不需要Mockito
        anagrafeUser = new AnagrafeUser();
    }

    @Test
    public void firstNameGetterSetterWorksCorrectly() {
        String testFirstName = "Alice";
        // 调用Setter赋值
        anagrafeUser.setFirstName(testFirstName);
        // 验证Getter返回值与设置值一致
        assertEquals(testFirstName, anagrafeUser.getFirstName());
    }

    @Test
    public void lastNameGetterSetterWorksCorrectly() {
        String testLastName = "Smith";
        anagrafeUser.setLastName(testLastName);
        assertEquals(testLastName, anagrafeUser.getLastName());
    }
}

这种写法的优势：

• 完全不需要Mockito（实体类无依赖，用Mock反而画蛇添足）
• 每个测试方法聚焦单个属性的Getter/Setter，逻辑清晰易维护
• 既满足代码覆盖要求，又能验证Setter赋值、Getter取值的正确性，比单纯的非空验证更有实际意义

针对强制覆盖实体类的通用建议 #

虽然从测试价值角度，不少开发者认为实体类的Getter/Setter无需专门测试（都是简单的赋值/取值逻辑），但既然客户明确要求覆盖，你可以：

1. 采用上面的「直接实例化+值验证」写法，简单高效
2. 如果项目有大量实体类需要测试，可借助工具自动生成测试代码（比如配合Lombok或JUnit 5参数化测试批量处理）
3. 避免滥用Mockito，实体类无依赖时，直接new对象是最简洁的选择

内容的提问来源于stack exchange，提问作者qwerty98