本文详解如何在 Gradle 多模块结构中，从模块 A 的 test 任务中精准控制并排除模块 B 的部分测试类执行，避免全局运行子模块测试，实现按需、隔离、可维护的测试调度。
本文详解如何在 gradle 多模块结构中，从模块 a 的 `test` 任务中精准控制并排除模块 b 的部分测试类执行，避免全局运行子模块测试，实现按需、隔离、可维护的测试调度。
在 Gradle 多模块项目中，当模块 A 通过 implementation project(':B')（或旧版 compile project(':B')）依赖模块 B 时，直接执行 ./gradlew test 会触发所有子项目（包括 A 和 B）的 test 任务。这意味着模块 B 的全部测试类（无论是否需要）都会被执行——这不仅浪费资源，还可能因环境冲突、数据污染或测试耦合导致失败。你尝试在模块 A 中配置 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/java/...）。例如，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 的设计哲学，也保障了构建的可预测性与可维护性。
