多模块项目中使用Fake Objects测试的最佳实践及相关疑问

1. 多模块环境中创建测试模块提供Fake Objects是否为常见实践？ #

这绝对是多模块项目里的成熟实践，很多中大型项目都会专门维护一个测试公共模块（比如命名为test-fakes、test-common或者shared-test），把跨模块复用的Fake实现、测试工具类、通用测试配置都放在这里。

这么做的核心优势：

• 彻底避免重复造轮子：不用每个业务模块都写一遍相同的Fake实现，减少代码冗余
• 保证Fake行为一致性：所有模块用的都是同一套Fake，不会出现不同模块Fake逻辑不一致导致的测试问题
• 降低维护成本：Fake需要更新时，只改一处就能同步到所有依赖的模块

比如很多Spring生态的项目，会把跨模块的Fake Repository、Fake Client都放到公共测试模块里，业务模块的测试用例直接依赖这个模块即可。

2. QueryDsl动态查询场景下如何创建Fake Objects？ #

针对QueryDsl的动态查询，Fake的核心是模拟Predicate条件的内存过滤逻辑，有两种常用方案：

方案一：手动实现内存过滤 #

自己写Fake Repository，实现对应的QueryDsl接口，内部用内存集合存储测试数据，直接利用Predicate的test方法判断对象是否符合条件：

public class FakeUserRepository implements UserRepository {
    private final List<User> users = new ArrayList<>();

    @Override
    public List<User> findAll(Predicate predicate) {
        return users.stream()
                .filter(user -> predicate.test(user))
                .collect(Collectors.toList());
    }

    // 其他接口方法的实现...
}

这种方式适合Predicate逻辑简单的场景，实现成本低。

方案二：借助Querydsl Collections库 #

Querydsl提供了querydsl-collections模块，支持在内存集合上执行QueryDsl查询，Fake实现会更简洁，无需手动处理复杂条件：

public class FakeUserRepository implements UserRepository {
    private final List<User> users = new ArrayList<>();
    private final QUser qUser = QUser.user;

    @Override
    public List<User> findAll(Predicate predicate) {
        return new JPAQuery<>(users)
                .from(qUser)
                .where(predicate)
                .fetch();
    }
}

这个库会自动把QueryDsl的Predicate转换成内存集合的查询逻辑，适合Predicate逻辑复杂的场景。

其他高效替代策略 #

除了公共测试模块的Fake，还有几种场景化的替代方案：

• Testcontainers：如果依赖模块C、D、E是数据库、消息队列这类服务，直接用Testcontainers启动轻量级的真实实例，不用写Fake，测试更贴近生产环境。缺点是启动速度略慢，适合集成测试场景。
• Mockito Stubbing：对于逻辑简单的依赖，直接用Mockito的when(...).thenReturn(...)来Stub返回值，比写Fake更轻量。但要注意避免过度Mock，尤其是复杂的业务逻辑依赖，Mock容易导致测试和真实行为脱节。
• 契约测试（Contract Testing）：如果依赖模块是外部服务，用Pact、Spring Cloud Contract这类工具定义契约，测试时用契约生成的Stub替代真实服务，既不用自己写Fake，还能保证和真实服务的行为一致。
• 测试配置复用：用依赖注入框架的测试配置（比如Spring的@TestConfiguration），把Fake Bean的定义放到公共测试模块，业务模块测试时直接导入配置即可，不用重复定义Fake。

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