Gradle多模块：主模块精确排除子模块特定测试类

本文详解如何在 Gradle 多模块结构中，从模块 A 的 test 任务中精准控制并排除模块 B 的部分测试类执行，避免全局运行子模块测试，实现按需、隔离、可维护的测试调度。

在 Gradle 多模块项目中，当模块 A 通过 implementation project(':B')（或旧版 compile project(':B')）依赖模块 B 时，直接执行 ./gradlew test 会触发所有子项目（包括 A 和 B）的 test 任务。这意味着模块 B 的全部测试类——无论是否需要——都会被执行。这不仅仅是浪费资源，还可能因环境冲突、数据污染或测试耦合导致失败，让人头疼不已。

你可能会尝试在模块 A 的 test 配置中这样写：excludes = ["B/src/test/**"]。但结果往往是无效的，为什么？根本原因在于：Gradle 的 test 任务默认只扫描本模块 src/test 下的类，不会主动扫描或加载其他子项目的源码路径；excludes 是针对当前任务 classpath 中已经加载的测试类进行过滤，而模块 B 的测试类压根没有被模块 A 的 test 任务纳入扫描范围，排除规则自然不生效。

那么，正确的做法是什么？核心思路是职责分离 + 显式任务编排。下面给出两种经过验证的解决方案。

方案一：仅执行模块 A 的测试（最简有效）

./gradlew A:test

这条命令明确指定只运行模块 A 的 test 任务，完全跳过模块 B 的测试执行。这是最轻量、最符合单一职责原则的做法，适用于“模块 A 不应承担模块 B 测试责任”的场景。多数情况下，这才是你真正需要的。

方案二：定制模块 B 的测试任务，并由模块 A 按需调用（精细控制）

如果业务逻辑确实要求模块 A 的集成测试必须包含模块 B 的部分测试——比如共享工具类的契约测试——那就需要在模块 B 中定义一个专用测试任务，显式排除不需要的类：

// 在 module B 的 build.gradle 中
tasks.register('filteredTest', Test) {
    // 指向模块 B 自身的测试源集
    testClassesDirs = sourceSets.test.output.classesDirs
    classpath = sourceSets.test.runtimeClasspath

    // 精确排除特定测试类（支持 Ant 风格通配符）
    exclude '**/IntegrationSmokeTest.class'
    exclude '**/SlowExternalApiTest.class'
    exclude 'com/example/b/**/LegacyServiceTest.class'
    // 或批量排除整个包
    // exclude 'com/example/b/legacy/**'
}

然后，在模块 A 的 build.gradle 中，让其 test 任务依赖这个定制任务：

// 在 module A 的 build.gradle 中
test {
    dependsOn ':B:filteredTest'
    // 可选：禁止默认执行 B:test（确保无冗余执行）
    finalizedBy ':B:filteredTest'
}

这里有几个关键细节值得注意：

• 路径写法辨析：exclude 接收的是相对于 testClassesDirs 的类路径（.class 文件路径），不是源码路径（如 src/test/ja va/...）。例如，com.example.b.FooTest 编译后为 com/example/b/FooTest.class，对应 exclude 'com/example/b/FooTest.class'。
• 避免 excludes 误用：test { excludes = [...] } 中的 excludes 是 List 类型，但更推荐使用 exclude(...) 方法链式调用，直接赋值容易被覆盖或忽略。
• 版本兼容性：Gradle 6.0+ 推荐使用 tasks.register() 创建延迟配置任务（如 filteredTest），而非 task()，以提升构建性能。
• 测试隔离性：模块间测试不应强耦合。长期来看，建议将跨模块契约测试提取为独立模块，或使用 testFixtures 共享测试资源，而不是在 A 中驱动 B 的测试。

总结一下：Gradle 的测试执行粒度天然绑定于项目边界。想从模块 A 控制模块 B 的测试行为，核心思路不是“在 A 中过滤 B 的路径”，而是在 B 中定义可控的测试契约，并在 A 中声明性地组合调用。这既符合 Gradle 的设计哲学，也让构建的预测性和可维护性大大提升。