1. DataJpaTest中集合断言的常见问题
在Spring Boot项目中，@DataJpaTest注解常用于测试JPA仓库层的功能。它提供了一个轻量级的测试环境，只加载与JPA相关的组件。然而，在编写测试时，开发者可能会遇到一个令人费解的场景：单个测试方法（例如shouldFindSingleRecipeByName()）可以成功通过，但当整个测试类或所有测试一起运行时，部分测试却会失败，并抛出org.opentest4j.AssertionFailedError。
典型的错误信息如下：
expected: "[com.example.recipesapi.model.Recipe@45f421c] (List12@14983265)" but was: "[com.example.recipesapi.model.Recipe@45f421c] (ArrayList@361483eb)"
这个错误表明，尽管预期和实际的Recipe对象内容（通过equals方法比较）可能相同，但它们所包含的List集合的底层实现类型不同。例如，预期列表可能是List.of()创建的List12（Java 9+的内部不可变列表类型），而实际从JPA仓库返回的列表可能是ArrayList。assertThat(...).isEqualTo(...)断言在比较集合时，可能会对这种类型差异非常敏感，导致断言失败。
为了更好地说明问题，以下是一个典型的测试类和实体类结构：
// RecipeRepositoryTest.java
@DataJpaTest
class RecipeRepositoryTest {
@Autowired
private RecipeRepository recipeRepositoryUnderTest;
@BeforeEach
void tearDown() {
// 在每个测试方法执行前清理数据库，确保测试隔离
recipeRepositoryUnderTest.deleteAll();
}
@Test
void shouldFindSingleRecipeByName() {
// given
String searchName = "Tomato soup";
Recipe recipe1 = new Recipe(1L, "Tomato soup", "Delicious tomato soup", Arrays.asList("1. ", "2. "), Arrays.asList("1. ", "2. "));
Recipe recipe2 = new Recipe(2L, "Mushrooms soup", "Delicious mushrooms soup", Arrays.asList("1. ", "2. "), Arrays.asList("1. ", "2. "));
recipeRepositoryUnderTest.saveAll(List.of(recipe1, recipe2));
// when
List<Recipe> recipesList = recipeRepositoryUnderTest.findRecipeByName(searchName.toLowerCase());
// then
// 这里的 isEqualTo 是导致问题的关键点
assertThat(recipesList).isEqualTo(List.of(recipe1));
}
// 其他测试方法，例如：
@Test
void shouldFindTwoRecipesByName() {
// ... (省略部分代码)
// then
// assertThat(recipesList).isEqualTo(List.of(recipe1, recipe2)); // 同样可能出现问题
}
@Test
void findByNameShouldReturnEmptyListOfRecipes() {
// ... (省略部分代码)
// then
// assertThat(recipesList).isEqualTo(List.of()); // 对于空列表通常不会有问题，但使用更语义化的断言更好
}
}// Recipe.java
@AllArgsConstructor
@NoArgsConstructor
@Getter
@Entity
@Table(name = "Recipes")
public class Recipe {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
@NotBlank
@NotNull
@NotEmpty
private String name;
@NotNull
@NotEmpty
@NotBlank
private String description;
@ElementCollection
private List<String> ingredients;
@ElementCollection
private List<String> directions;
@Override
public boolean equals(final Object o) {
if (this == o) return true;
if (o == null || Hibernate.getClass(this) != Hibernate.getClass(o)) return false;
final Recipe recipe = (Recipe) o;
return id != null && Objects.equals(id, recipe.id);
}
@Override
public int hashCode() {
return getClass().hashCode(); // 注意：此hashCode实现可能存在潜在问题，但非本次List断言失败的直接原因
}
}2. isEqualTo与集合比较的原理分析
AssertJ库的isEqualTo方法在比较两个对象时，通常会调用对象的equals()方法。然而，对于集合类型，其行为可能更加复杂。当比较两个List实例时，isEqualTo不仅会检查列表中的每个元素是否相等（通过元素的equals()方法），还可能隐含地检查列表的具体实现类型。
List.of()方法是Java 9引入的工厂方法，用于创建不可变列表。这些列表的内部实现是高度优化的，通常是java.util.ImmutableCollections$ListN或类似的内部类（例如错误信息中的List12）。而当JPA（通过Hibernate实现）从数据库中检索数据时，它通常会返回一个可变的java.util.ArrayList实例，或者在某些情况下，会返回Hibernate内部的代理集合（如PersistentBag）。
尽管这两个列表可能包含逻辑上相等的Recipe对象（因为Recipe的equals方法基于ID），但由于它们的运行时类型不同（List12 vs ArrayList），isEqualTo断言可能会认为它们是不同的，从而导致测试失败。单个测试通过而集体测试失败，可能是由于JVM的类加载、缓存行为或测试执行顺序等细微差异，使得在特定隔离环境下，类型差异的影响被最小化，但在并行或连续执行时，这种差异变得显著。
3. 健壮的集合断言解决方案
为了解决这个问题，我们应该使用更专注于集合内容和元素顺序的断言方法，而不是严格依赖于集合的具体实现类型。
3.1 方案一：使用containsExactly或containsExactlyInAnyOrder (推荐)
AssertJ提供了专门用于集合断言的方法，它们更加健壮和语义化。
- containsExactly(E... expected): 断言实际集合与预期集合包含完全相同的元素，并且元素的顺序也必须一致。
- containsExactlyInAnyOrder(E... expected): 断言实际集合与预期集合包含完全相同的元素，但不要求元素的顺序一致。
根据你的测试场景，选择合适的断言方法。在shouldFindSingleRecipeByName()的例子中，我们预期只返回一个特定的Recipe，且通常顺序不重要（除非查询明确指定了排序），containsExactly是合适的，因为它同时也验证了数量。如果预期返回多个元素且顺序不确定，containsExactlyInAnyOrder会更合适。
**修改后的
