在 java 单元测试中，通常不需要为标准的 getter 和 setter 方法编写测试用例。getter 和 setter 只是简单的数据访问器，其逻辑完全由编译器生成的字节码保证，且遵循 javabeans 规范，手动测试它们属于过度工程化，只会增加维护成本而不会带来实质性的质量保障。
为什么 Getter/Setter 不值得单独测试
Getter 和 Setter 的本质是字段访问的封装，它们不包含业务逻辑。例如，一个名为 getName() 的方法仅仅返回私有字段 name 的值；一个名为 setName(String name) 的方法仅仅将参数赋值给该字段。这种操作在 JVM 层面是确定性的，任何现代 IDE 或构建工具生成的代码都严格遵循这一行为。如果对这些方法进行单元测试，你实际上是在测试 Java 语言本身的基础功能，而非你的代码逻辑。此外，随着项目迭代，如果重构了字段名或类型，所有相关的 Getter/Setter 测试都需要更新，这违背了单元测试应关注业务规则变化的初衷。
public class User {
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
上述代码展示了最基础的 JavaBean 结构。对于此类代码，运行 mvn test 时若包含针对 getName 的断言，虽然能通过，但并未验证任何自定义逻辑。相反，应将测试重点放在使用这些字段的业务方法上，例如验证当 name 被设置后，其他依赖该字段的方法（如 isValid()）是否能正确响应。
何时需要警惕 Setter 中的逻辑
虽然纯赋值型的 Setter 无需测试，但如果 Setter 中包含校验、转换或副作用逻辑，则必须对其进行测试。例如，当 Setter 负责验证输入非空、修剪空格或触发事件通知时，它就不再是一个简单的访问器，而是承载了业务规则。此时，测试的重点不再是“值是否被存储”，而是“输入是否符合预期”以及“副作用是否发生”。这种情况下，应将 Setter 视为业务逻辑的一部分，并编写相应的边界条件测试。
public class User {
private String email;
public void setEmail(String email) {
if (email == null || !email.contains("@")) {
throw new IllegalArgumentException("Invalid email");
}
this.email = email;
}
public String getEmail() {
return email;
}
}
在上述代码中，setEmail 包含了格式校验逻辑。测试此方法时，需分别传入有效邮箱、null 值和无效格式字符串，验证异常抛出行为。这与纯 Getter/Setter 的测试策略截然不同，因为它涉及具体的业务约束。因此，判断是否需要测试的关键在于：该方法是否仅执行字段读写？如果是，跳过测试；如果不是，纳入测试范围。
基于程序中某个输入、条件或结果的具体问题
在实际开发中，常遇到的问题是：当 Setter 被调用后，如何确保对象状态的一致性而不直接测试 Setter？答案是通过测试依赖该字段的其他公共方法。例如，若 User 类有一个 getDisplayName() 方法，它依赖于 name 字段，那么通过测试 getDisplayName() 的正确性，间接验证了 setName() 是否成功更新了内部状态。这种方式避免了重复测试底层数据访问，同时确保了业务行为的正确性。若 name 为空，getDisplayName() 应返回默认值或抛出异常，具体取决于设计。通过覆盖这些场景，可以全面验证对象的行为，而无需关心内部的 Getter/Setter 实现细节。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
