如何测试复杂的Criteria API逻辑？求替代Mockito的单元测试方案

1. 直接生成SQL并断言 #

Criteria API的核心价值就是生成符合业务逻辑的SQL，所以直接验证生成的SQL结构是最直接的方式，不用纠结多层Mock的问题。

• 实现思路：借助你使用的JPA提供者（比如Hibernate）的内部API，把构建好的CriteriaQuery转换成SQL字符串，然后断言SQL里是否包含预期的JOIN语句、WHERE条件、排序规则等。
• 代码示例：

// 假设你已经构建好CriteriaQuery<YourEntity> criteria
EntityManager em = entityManagerFactory.createEntityManager();
Query query = em.createQuery(criteria);
// 针对Hibernate的转换方式，其他JPA提供者可调整适配
String generatedSql = ((org.hibernate.query.Query) query).getQueryString();

// 断言SQL符合预期
assertTrue(generatedSql.contains("JOIN user u ON o.user_id = u.id"));
assertTrue(generatedSql.contains("WHERE o.create_time >= '2024-01-01'"));

• 优势：直接验证最终输出的SQL，完全贴合实际执行效果，避免Mock带来的脱离真实场景的问题。

2. 用内存数据库做集成测试 #

把Criteria API的逻辑和内存数据库（比如H2）结合，通过真实的数据查询结果来验证逻辑正确性。

• 操作步骤：
  • 配置测试环境连接H2内存库，确保JPA映射、关联关系和生产环境一致；
  • 插入预设的测试数据（比如不同状态的实体、带关联的父子实体）；
  • 调用你的Criteria查询方法，获取结果列表；
  • 断言结果的数量、内容是否符合预期。
• 代码示例：

@Test
void testPaidOrdersWithUser() {
    // 插入测试数据
    User testUser = new User("test@example.com");
    entityManager.persist(testUser);
    
    Order paidOrder = new Order(testUser, OrderStatus.PAID, BigDecimal.valueOf(100));
    entityManager.persist(paidOrder);
    Order unpaidOrder = new Order(testUser, OrderStatus.UNPAID, BigDecimal.valueOf(50));
    entityManager.persist(unpaidOrder);

    // 调用查询方法
    List<Order> result = orderRepository.findPaidOrdersByUserId(testUser.getId());

    // 断言结果
    assertEquals(1, result.size());
    assertEquals(OrderStatus.PAID, result.get(0).getStatus());
}

• 优势：能验证从Criteria构建到数据查询的完整链路，包括JPA映射、关联处理的正确性，比单纯单元测试更贴近真实业务场景。

3. 拆分复杂逻辑为可测试的小单元 #

把100多行的代码拆分成多个单一职责的小方法，比如单独负责构建某类Predicate、创建特定关联JOIN、处理排序规则等，然后逐个测试这些小方法。

• 拆分示例：

// 单独处理状态条件的方法
private Predicate buildOrderStatusPredicate(CriteriaBuilder cb, Root<Order> root, OrderStatus status) {
    if (status == null) {
        return cb.conjunction(); // 返回无作用的空条件
    }
    return cb.equal(root.get("status"), status);
}

// 单独构建用户关联的方法
private Join<Order, User> buildUserJoin(Root<Order> root) {
    return root.join("user", JoinType.INNER);
}

• 小方法测试示例：

@Test
void testBuildOrderStatusPredicate() {
    CriteriaBuilder cb = entityManagerFactory.getCriteriaBuilder();
    Root<Order> root = cb.createQuery(Order.class).from(Order.class);
    
    Predicate predicate = buildOrderStatusPredicate(cb, root, OrderStatus.PAID);
    
    // 验证条件类型，或结合SQL生成方式断言具体内容
    assertTrue(predicate instanceof EqualPredicate);
}

• 优势：降低单个测试的复杂度，每个测试只聚焦一个小逻辑，出现问题时更容易定位。

4. 使用专门的JPA Mock工具简化单元测试 #

如果坚持做纯单元测试，别手动搞多层Mock，用专门适配JPA Criteria的Mock库（比如mockito-jpa）来简化Mock逻辑，专注验证API调用的正确性。

• 代码示例：

// 初始化Mock对象
CriteriaBuilder cb = mock(CriteriaBuilder.class);
Root<Order> root = mock(Root.class);
Path<OrderStatus> statusPath = mock(Path.class);

// 预设Mock行为
when(root.get("status")).thenReturn(statusPath);
when(cb.equal(eq(statusPath), eq(OrderStatus.PAID))).thenReturn(mock(Predicate.class));

// 调用待测试方法
Predicate result = buildOrderStatusPredicate(cb, root, OrderStatus.PAID);

// 断言交互是否符合预期
verify(cb).equal(statusPath, OrderStatus.PAID);

• 优势：比手动嵌套Mock简洁很多，减少Mock代码的冗余，更聚焦于逻辑本身的验证。

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