Gradle多模块依赖：api与testImplementation组合使用等价性问询

Hey there! Let’s dig into whether these two approaches for sharing test dependencies are equivalent—spoiler: they’re not, and the difference matters for your build’s sanity.

先回顾两种实现方式 #

方案1：用api暴露测试依赖 #

在testshared模块的构建脚本中，直接用生产级的api配置暴露测试所需的依赖：

// testshared/build.gradle
api libraries.lib1
api libraries.lib2

然后在moduleA中通过测试配置引入整个模块：

// moduleA/build.gradle
testImplementation project(':testshared')

方案2：自定义测试专用配置 #

先在testshared中定义一个继承自testImplementation的自定义配置，再把测试依赖放到testImplementation里：

// testshared/build.gradle
configurations {
    myTestDependencies.extendsFrom testImplementation
}
dependencies {
    testImplementation libraries.lib1
    testImplementation libraries.lib2
    // .. 其他testImplementation依赖
}

接着moduleA明确指定引用这个自定义测试配置：

// moduleA/build.gradle
testImplementation project(path: ':testshared', configuration: 'myTestDependencies')

核心差异：安全性与语义正确性 #

这两种方式最终都能让moduleA的测试代码获取到lib1和lib2，但它们的语义和潜在风险完全不同：

• 方案1的隐患：api是Gradle用于暴露生产代码依赖的配置。如果有其他模块不小心用implementation project(':testshared')（而非testImplementation）引入这个模块，你的测试依赖会被错误地混入生产代码的类路径中——这绝对是你不想看到的，测试依赖不该出现在生产环境里。
• 方案2的合理性：自定义的myTestDependencies是专门为测试场景设计的配置，它明确继承自testImplementation，只会传递测试相关的依赖。只有当其他模块主动指定引用这个配置时，才会拿到这些依赖，从根源上避免了污染生产类路径的风险。

简单总结：方案1是“借生产的管道传测试依赖”，存在安全隐患；方案2是“为测试依赖单独开了合规通道”，是更规范、更安全的做法。

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