在 Gradle 多模块项目中，当模块 A 依赖模块 B（通过 compile project(':B')）时，直接运行 ./gradlew test 会默认执行所有子模块的测试任务。本文介绍如何从模块 A 出发，精准排除模块 B 中特定测试类的执行，避免侵入式修改模块 B 的配置。
在 gradle 多模块项目中，当模块 a 依赖模块 b（通过 `compile project(':b')`）时，直接运行 `./gradlew test` 会默认执行所有子模块的测试任务。本文介绍如何从模块 a 出发，精准排除模块 b 中特定测试类的执行，避免侵入式修改模块 b 的配置。
Gradle 的 test 任务作用域是每个子项目独立的。当你在根目录或模块 A 中执行 ./gradlew test，Gradle 实际上会依次执行 A:test 和 B:test —— 这意味着你在模块 A 的 build.gradle 中配置 test { excludes = [...] } 仅影响模块 A 自身的测试类路径，对模块 B 的 test 任务完全无效。你尝试的 excludes = ["B/src/test/**"] 之所以不生效，正是因为该配置未作用于模块 B 的测试任务，且路径模式本身也不符合 Gradle Test 任务的 exclude 规则（它匹配的是类名（如 com.example.BTest），而非文件系统路径）。
✅ 正确解决方案：按需调用 + 自定义测试任务
要实现“由模块 A 全权控制模块 B 的测试行为”，推荐采用显式任务依赖 + 模块 B 提供定制化测试任务的方式，既解耦又可控：
步骤 1：在模块 B 中定义专用测试任务（推荐使用 Test 类型）
// B/build.gradle
tasks.register('filteredTest', Test) {
// 排除指定测试类（支持通配符）
exclude '**/IntegrationTest.class'
exclude '**/SlowTest.class'
exclude 'com/example/b/FlakyTestCase.class'
// 可选：指定测试类路径（确保只加载 B 的测试）
classpath = sourceSets.test.output + sourceSets.test.runtimeClasspath
}
? 提示：exclude 接受基于 类全限定名 的 Ant 风格模式（如 **/MyTest.class），不是源码路径。编译后类位于 build/classes/java/test/，对应类名为 com.example.MyTest → 文件路径为 com/example/MyTest.class。
步骤 2：在模块 A 中覆盖默认行为，仅依赖定制任务
// A/build.gradle
// 方案一：完全跳过 B:test，只执行 B:filteredTest
test.dependsOn 'B:filteredTest'
test.mustRunAfter 'B:filteredTest' // 确保顺序（可选）
// 方案二（更彻底）：禁用 B 的默认 test 任务（谨慎使用）
// configure(subprojects.find { it.name == 'B' }) {
// tasks.named('test').configure { enabled = false }
// }
✅ 替代快捷方案：直接运行单模块测试
若无需混合执行 A/B 测试，最简方式是避免全局 test：
# 仅运行模块 A 的测试（B 的 test 任务根本不会触发） ./gradlew A:test # 或明确排除 B（适用于 Gradle 7.4+） ./gradlew test --exclude-subproject=B
⚠️ 注意事项与最佳实践
- ❌ 不要试图在 A 中通过 test { excludes } 影响 B 的测试 —— 这违反 Gradle 任务隔离原则；
- ✅ 优先使用 tasks.register(...)（Gradle 6.0+ 推荐）而非 task ...
- ? 验证排除效果：运行 ./gradlew B:filteredTest --info 查看实际执行的测试类列表；
- ? 若需动态控制（如按环境排除），可在 filteredTest 中结合 systemProperty 或 project.property 实现条件排除；
- ? 对于测试资源隔离，还可配合 test.include 精确指定白名单，比 exclude 更安全。
通过以上方式，模块 A 获得了对模块 B 测试执行的完整话语权，同时保持了模块边界的清晰性与构建脚本的可维护性。
