在java junit单元测试中，当使用`assertequals`比较两个看似相同的复杂对象时，测试可能意外失败。本文深入探讨了这一问题的根本原因——java对象`equals()`方法的默认行为，并提供了三种有效的解决方案：正确实现`equals()`和`hashcode()`方法、逐一比较对象字段，以及利用assertj库进行强大的递归比较，旨在帮助开发者编写更健壮、准确的单元测试。
引言：理解assertEquals的默认行为
在Java的单元测试中，我们经常需要断言方法返回的对象是否符合预期。JUnit的assertEquals(Object expected, Object actual)方法是进行对象比较的常用工具。然而，许多开发者会遇到一个常见的问题：即使两个对象的toString()输出看起来完全相同，assertEquals仍然报告测试失败，并显示类似以下信息：
Expected :Customer{Id=1, Name='ABC', Price=350, Type='ABC'}
Actual :Customer{Id=1, Name='ABC', Price=350, Type='ABC'}这背后的原因是，assertEquals方法在比较非基本类型对象时，默认调用的是对象的equals()方法。如果您的自定义类（如Customer）没有重写equals()方法，它将继承Object类中的默认实现。Object类的equals()方法仅仅比较两个对象的内存地址（即this == obj），只有当它们指向同一个内存中的对象时才返回true。因此，即使两个对象具有相同的属性值，但如果它们是不同的实例，assertEquals也会认为它们不相等。
要解决这个问题，我们需要采取更精细的比较策略。
核心方法：正确实现equals()与hashCode()
解决复杂对象比较问题的最根本和推荐方法是，在您的自定义类中正确重写equals()和hashCode()方法。这两个方法通常是成对出现的，并且必须遵循特定的契约，以确保对象在集合（如HashMap、HashSet）中能正常工作。
立即学习“Java免费学习笔记（深入）”；
equals()方法契约：
- 自反性 (Reflexive)： 对于任何非null的引用值x，x.equals(x)必须返回true。
- 对称性 (Symmetric)： 对于任何非null的引用值x和y，当且仅当y.equals(x)返回true时，x.equals(y)才返回true。
- 传递性 (Transitive)： 对于任何非null的引用值x、y和z，如果x.equals(y)返回true且y.equals(z)返回true，那么x.equals(z)必须返回true。
- 一致性 (Consistent)： 对于任何非null的引用值x和y，在equals比较中所用的信息没有被修改的情况下，多次调用x.equals(y)应该始终返回相同的结果。
- 对于null的约定： 对于任何非null的引用值x，x.equals(null)必须返回false。
hashCode()方法契约：
- 在Java应用程序的执行期间，如果对同一个对象多次调用hashCode()方法，则它必须始终返回相同的整数，前提是对象中equals比较中所用的信息没有被修改。
- 如果两个对象根据equals(Object)方法是相等的，那么对这两个对象中的每个对象调用hashCode方法都必须生成相同的整数结果。
- 如果两个对象根据equals(Object)方法是不相等的，那么对这两个对象中的每个对象调用hashCode方法，不要求生成不同的整数结果。但是，为不相等的对象生成不同的整数结果可以提高哈希表的性能。
示例：Customer类实现equals()和hashCode()
假设我们有一个Customer类，包含id、name、price和type字段。
未实现equals()和hashCode()的Customer类：
public class Customer {
private Long id;
private String name;
private double price;
private String type;
public Customer(Long id, String name, double price, String type) {
this.id = id;
this.name = name;
this.price = price;
this.type = type;
}
// Getters and Setters
public Long getId() { return id; }
public void setId(Long id) { this.id = id; }
public String getName() { return name; }
public void setName(String name) { this.name = name; }
public double getPrice() { return price; }
public void setPrice(double price) { this.price = price; }
public String getType() { return type; }
public void setType(String type) { this.type = type; }
@Override
public String toString() {
return "Customer{" +
"Id=" + id +
", Name='" + name + '\'' +
", Price=" + price +
", Type='" + type + '\'' +
'}';
}
}使用上述类进行JUnit测试，即使属性相同，assertEquals也会失败：
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;
public class CustomerTest {
@Test
void getCustomerById_Test_FailsWithoutEqualsHashCode() {
Customer expectedCustomer = new Customer(1L, "ABC", 350.0, "TypeA");
Customer actualCustomer = new Customer(1L, "ABC", 350.0, "TypeA");
// 此断言将失败，因为它们是不同的对象实例，且未重写equals方法
// assertEquals(expectedCustomer, actualCustomer);
// 如果我们只想看效果，可以这样测试：
// System.out.println(expectedCustomer.equals(actualCustomer)); // 输出 false
}
}实现equals()和hashCode()的Customer类：
为了方便，我们通常会使用IDE（如IntelliJ IDEA）自动生成或使用Lombok库的@EqualsAndHashCode注解来完成。
import java.util.Objects;
public class Customer {
private Long id;
private String name;
private double price;
private String type;
public Customer(Long id, String name, double price, String type) {
this.id = id;
this.name = name;
this.price = price;
this.type = type;
}
// Getters and Setters (同上)
public Long getId() { return id; }
public void setId(Long id) { this.id = id; }
public String getName() { return name; }
public void setName(String name) { this.name = name; }
public double getPrice() { return price; }
public void setPrice(double price) { this.price = price; }
public String getType() { return type; }
public void setType(String type) { this.type = type; }
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
Customer customer = (Customer) o;
return Double.compare(customer.price, price) == 0 &&
Objects.equals(id, customer.id) &&
Objects.equals(name, customer.name) &&
Objects.equals(type, customer.type);
}
@Override
public int hashCode() {
return Objects.hash(id, name, price, type);
}
@Override
public String toString() {
return "Customer{" +
"Id=" + id +
", Name='" + name + '\'' +
", Price=" + price +
", Type='" + type + '\'' +
'}';
}
}现在，使用重写了equals()和hashCode()方法的Customer类进行测试，assertEquals将成功：
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;
public class CustomerTest {
@Test
void getCustomerById_Test_SucceedsWithEqualsHashCode() {
Customer expectedCustomer = new Customer(1L, "ABC", 350.0, "TypeA");
Customer actualCustomer = new Customer(1L, "ABC", 350.0, "TypeA");
// 此断言将成功
assertEquals(expectedCustomer, actualCustomer);
}
}替代方案一：字段逐一比较
在某些情况下，您可能不希望或无法修改类的equals()和hashCode()方法（例如，处理第三方库的对象，或者只想在特定测试场景中比较部分字段）。此时，您可以选择逐一比较对象的关键字段。
这种方法的优点是简单直接，不需要修改被测试类。缺点是如果对象包含大量字段，代码会变得冗长且难以维护；如果未来添加或删除了字段，您可能需要更新所有的测试代码。
示例：逐一比较Customer对象的字段
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;
public class CustomerFieldComparisonTest {
@Test
void getCustomerById_Test_FieldByField() {
Customer expectedCustomer = new Customer(1L, "ABC", 350.0, "TypeA");
// 假设这是从某个服务或仓库返回的实际对象
Customer actualCustomer = new Customer(1L, "ABC", 350.0, "TypeA");
assertEquals(expectedCustomer.getId(), actualCustomer.getId(), "ID should match");
assertEquals(expectedCustomer.getName(), actualCustomer.getName(), "Name should match");
assertEquals(expectedCustomer.getPrice(), actualCustomer.getPrice(), "Price should match");
assertEquals(expectedCustomer.getType(), actualCustomer.getType(), "Type should match");
}
}替代方案二：利用AssertJ进行递归比较
AssertJ是一个功能强大且提供流式API的Java断言库，它提供了比JUnit内置断言更丰富的特性，包括对复杂对象的深度（递归）比较。如果您项目中已经引入了AssertJ，或者愿意引入它，那么usingRecursiveComparison()方法将是处理复杂对象断言的优雅选择。
首先，确保您的项目中已添加AssertJ依赖。
Maven示例：
org.assertj assertj-core 3.25.3 test
示例：使用AssertJ进行递归比较
import org.junit.jupiter.api.Test;
import static org.assertj.core.api.Assertions.assertThat;
public class CustomerAssertJComparisonTest {
@Test
void getCustomerById_Test_UsingAssertJRecursiveComparison() {
Customer expectedCustomer = new Customer(1L, "ABC", 350.0, "TypeA");
Customer actualCustomer = new Customer(1L, "ABC", 350.0, "TypeA");
// AssertJ的递归比较，无需重写equals/hashCode
assertThat(actualCustomer)
.usingRecursiveComparison()
.isEqualTo(expectedCustomer);
}
@Test
void getCustomerById_Test_UsingAssertJRecursiveComparison_IgnoringFields() {
Customer expectedCustomer = new Customer(1L, "ABC", 350.0, "TypeA");
// 假设实际对象中某个字段（如type）是不同的，但我们希望忽略它
Customer actualCustomer = new Customer(1L, "ABC", 350.0, "TypeB");
// 递归比较，但忽略'type'字段
assertThat(actualCustomer)
.usingRecursiveComparison()
.ignoringFields("type") // 忽略type字段的比较
.isEqualTo(expectedCustomer);
}
}AssertJ的usingRecursiveComparison()方法非常灵活，它还提供了多种配置选项，例如：
- ignoringFields(String... fields)：忽略指定字段的比较。
- ignoringActualFields(String... fields)：只忽略实际对象中的指定字段。
- ignoringExpectedFields(String... fields)：只忽略预期对象中的指定字段。
- withComparatorForType(Comparator> comparator, Class> type)：为特定类型提供自定义比较器。
- withStrictTypeChecking(boolean strictTypeChecking)：开启或关闭严格类型检查。
这使得AssertJ成为处理复杂、嵌套对象断言的强大工具，尤其是在您不想（或不能）修改类equals()方法时。
注意事项与最佳实践
-
选择合适的策略：
- 对于数据传输对象（DTOs）或实体类（Entities）： 强烈建议实现equals()和hashCode()。这不仅对单元测试有益，对于将这些对象用作Map的键或Set的元素时也至关重要。
- 对于第三方库或无法修改的类： 字段逐一比较或使用AssertJ的递归比较是更好的选择。
- 对于只关心部分字段的测试： 字段逐一比较可能更清晰，或者使用AssertJ的ignoringFields()。
hashCode()的重要性： 始终记住，如果重写了equals()，就必须重写hashCode()，并确保它们保持一致的契约。否则，您的对象在哈希集合中可能会出现不可预测的行为。
测试粒度： 考虑您真正想测试的是什么。是整个对象的逻辑相等性，还是某个特定属性的正确性？这有助于您选择最合适的断言方法。
避免依赖toString()： 永远不要仅仅因为两个对象的toString()输出相同就认为它们相等。toString()方法主要用于调试和日志记录，其格式和内容不应作为对象相等性的判断依据。
引入外部库的考量： 引入AssertJ等外部断言库可以极大地提升测试代码的可读性和功能性。但也要权衡项目对外部依赖的接受程度。对于大多数现代Java项目，AssertJ已成为事实上的标准。
总结
在Java JUnit单元测试中正确断言复杂对象是编写高质量测试的关键。当遇到assertEquals对看似相同的对象报告失败时，核心问题通常在于对象没有正确实现equals()和hashCode()方法。通过理解equals()的默认行为并采取相应的策略，您可以有效地解决这个问题。
本文介绍了三种主要的解决方案：
- 实现equals()和hashCode()： 这是最根本和推荐的方法，尤其适用于DTOs和实体类。
- 字段逐一比较： 适用于不希望修改类或只关心部分字段的场景，但可能导致代码冗长。
- 使用AssertJ进行递归比较： 提供强大且灵活的深度比较能力，是处理复杂对象断言的优雅选择。
根据您的具体需求和项目背景，选择最适合的策略，将有助于您编写出更健壮、更易于维护的单元测试。
