本文介绍在 Gradle 多模块项目中，当模块 A 依赖模块 B（通过 compile project(':B')）时，如何在执行 ./gradlew test（针对模块 A）时不运行模块 B 的特定测试类——关键在于理解 Gradle 测试任务的作用域，并通过跨模块任务依赖与自定义测试任务实现精准控制。
本文介绍在 gradle 多模块项目中，当模块 a 依赖模块 b（通过 `compile project(':b')`）时，如何在执行 `./gradlew test`（针对模块 a）时不运行模块 b 的特定测试类——关键在于理解 gradle 测试任务的作用域，并通过跨模块任务依赖与自定义测试任务实现精准控制。
在 Gradle 多模块项目中，test 是一个项目级任务：执行 ./gradlew test 时，Gradle 会自动在所有参与构建的子项目（包括 A 和 B）中并行执行各自的 test 任务。因此，单纯在模块 A 的 build.gradle 中配置 test { excludes = [...] } 是无效的——该配置仅影响模块 A 自身的测试类扫描路径，对模块 B 的 test 任务完全无作用。你之前尝试的 excludes = ["B/src/test/**"] 之所以不生效，正是因为 excludes 是针对当前项目 src/test 目录下的类路径过滤，而非跨项目文件系统路径匹配。
✅ 正确解决方案：分场景选择策略
方案一：避免运行 B 的测试（推荐，最简洁）
若模块 A 的测试无需触发模块 B 的任何测试，直接指定目标项目执行即可：
./gradlew A:test
该命令仅执行模块 A 的 test 任务，模块 B 的测试完全不会被触发，零配置、零副作用，适用于绝大多数集成隔离场景。
方案二：有选择地运行 B 的部分测试（需定制化控制）
若业务逻辑要求模块 A 的测试流程中必须执行模块 B 的部分测试（如共享工具类验证），但需排除特定类，则需在模块 B 中定义专用测试任务，并在模块 A 中显式依赖：
-
在模块 B 的 build.gradle 中定义自定义测试任务：
// 模块 B/build.gradle tasks.register('selectiveTest', Test) { // 显式指定测试源集（确保使用 B 的测试代码） testClassesDirs = sourceSets.test.output.classesDirs classpath = sourceSets.test.runtimeClasspath // 排除指定测试类（支持通配符） exclude '**/IntegrationSmokeTest.class' exclude '**/LegacyApiTest.class' // 或按包排除 exclude 'com.example.b.legacy.**' // 可选：启用测试过滤（更灵活） include '**/Unit*Test.class' } -
在模块 A 的 build.gradle 中覆盖默认依赖关系：
// 模块 A/build.gradle test { // 移除对 B:test 的隐式依赖（Gradle 默认行为） dependsOn.remove('B:test') // 改为依赖 B 的定制任务 dependsOn 'B:selectiveTest' }
⚠️ 注意事项：
- exclude 接收的是 class 文件路径模式（编译后路径），非源码路径（如 src/test/java/...）。务必使用 **/ClassName.class 或 com/package/** 格式。
- 若使用 Kotlin DSL（build.gradle.kts），语法需调整：exclude("com/example/b/**")
- 避免在 test { excludes = [...] } 中写 B/src/test/** —— 这是无效路径，Gradle 不解析跨项目源码目录。
- 验证效果：执行 ./gradlew A:test --info，观察日志中是否出现 Executing task ':B:selectiveTest' 及被排除类的跳过提示。
总结
Gradle 的测试执行模型基于项目边界，跨模块测试控制必须通过任务依赖显式编排，而非路径式排除。优先采用 A:test 命令实现天然隔离；若需深度协同，则通过 register() 创建可复用的定制测试任务，并利用 dependsOn 精准串联。这种设计既符合 Gradle 的声明式构建哲学，也保障了多模块测试策略的可维护性与可追溯性。
