对“test-support”代码的 gradle 配置的反馈
Feedback on gradle configuration for `test-support` code
最近我一直在思考这个问题,想就我几天前的想法得到一些反馈。
问题:
在典型的代码库中,每个模块都有一个 main
和一个 test
源代码集。这在一段时间内可以很好地工作,但迟早我总是会偶然发现我想将一堆 类 组合在一起的情况,这样可以更轻松地测试涉及某个模块的代码。一个很好的例子是给定模块的一组 hamcrest
匹配器 类。
假设 1:
由于 hamcrest
是测试代码库,因此这些匹配器不应进入 main
源集。
假设二:
这些 类 也不应该进入 test
源集,因为对 test
源的依赖只是这些 类 可用的解决方法。人们通常不希望依赖于实际测试。
它也是 not recommended(由 Netflix)定义对项目 test
源集的依赖。
解决方案 1:
在 main
源集中创建一个包含这些 类 的专用模块,并在您需要的任何地方简单地定义此模块的测试依赖项。
这是我使用了一段时间的方法,但我不太喜欢它。
首先,我从来没有想出一个好听的名字,除了将 testSupport
附加到原始模块的名称,这导致名称像 core-testSupport
、persistence-testSupport
等等。
其次,它创建了很多模块,项目树被这些模块污染了。
解决方案 2:(我希望得到反馈的那个)
configurations {
testSupportCompile.extendsFrom compile
testSupportRuntime.extendsFrom runtime
}
sourceSets {
testSupport {
compileClasspath += sourceSets.main.output + configurations.testSupportCompile
runtimeClasspath += compileClasspath + configurations.testSupportRuntime
}
}
task testSupportJar(type: Jar) {
from sourceSets.testSupport.output
classifier 'testSupport'
}
artifacts {
testSupportCompile testSupportJar
}
上面的 gradle 配置可以放在名为 testSupport.gradle
的文件中,并应用于需要此专用源集以提供可在测试中重复使用的 类 的任何模块。
定义依赖项将像这样工作:
testCompile project(path: ':core', configuration: 'testSupportCompile')
我对 gradle 还是个新手,研究了很多,但我仍然有几个问题。
我知道声明一个新的源集会自动创建两个配置:<sourceSet>Compile
和 <sourceSet>Runtime
。我不太喜欢这种方法的是,在声明依赖项时必须使用 testSupportCompile 配置。有没有办法将其别名为 testSupport
或类似的别名?
我的项目目前可以正常编译。但是,我不确定我是否以正确的方式做事。这个配置怎么改进?
是否有任何其他方法可以实现所需的功能?在研究过程中,我并没有真正找到关于这个主题的太多信息,这让我觉得我要么使用了错误的搜索词,要么做了一些根本不应该做的愚蠢事情。
我知道这是一个宽泛的问题,但我不确定除了此处之外,在哪里可以获得关于此类问题的适当反馈。
我有类似的情况,我已经推迟了一段时间的解决方案,使用了各种 hack 和解决方法。你的问题是调查它的最终动机。
这就是我最终得到的——EDIT 与 Thomas 合作完成的:
configurations {
// create a new configuration and inherit everything from compile
testlib.extendsFrom compile
}
sourceSets {
testlib {
// We will at least need access to our main sourceSet and all dependencies that are declared for our configuration.
compileClasspath += sourceSets.main.output + configurations.testlib
}
}
task testlibJar(type: Jar) {
from sourceSets.testlib.output
classifier 'testlib'
}
artifacts {
testlib testlibJar // include the classes into the new configuration
archives testlibJar // optional: include the support JAR into "uploadArchives", so it may also be used in other projects
}
然后,在依赖模块中,只需使用:
dependencies {
testCompile project(path: ':otherproject', configuration: 'testlib')
}
请注意,(空)testlibCompile
和 testlibRuntime
配置仍会创建(作为引入新 testlib
源集的结果),但我相信它是安全的无视他们。
另外,经常有项目自己的test
配置需要使用testlib
(项目测试依赖通用测试支持)。在这种情况下,您可以在同一项目的两个配置之间添加依赖关系:
testCompile project(path: ':myproject', configuration: 'testlib')
或单独增强编译和运行时类路径:
configurations {
testlib.extendsFrom compile
testCompile.extendsFrom testlib
}
sourceSets {
test {
compileClasspath += sourceSets.testlib.output
runtimeClasspath += sourceSets.testlib.output
}
}
最近我一直在思考这个问题,想就我几天前的想法得到一些反馈。
问题:
在典型的代码库中,每个模块都有一个 main
和一个 test
源代码集。这在一段时间内可以很好地工作,但迟早我总是会偶然发现我想将一堆 类 组合在一起的情况,这样可以更轻松地测试涉及某个模块的代码。一个很好的例子是给定模块的一组 hamcrest
匹配器 类。
假设 1:
由于hamcrest
是测试代码库,因此这些匹配器不应进入main
源集。假设二: 这些 类 也不应该进入
test
源集,因为对test
源的依赖只是这些 类 可用的解决方法。人们通常不希望依赖于实际测试。 它也是 not recommended(由 Netflix)定义对项目test
源集的依赖。
解决方案 1:
在 main
源集中创建一个包含这些 类 的专用模块,并在您需要的任何地方简单地定义此模块的测试依赖项。
这是我使用了一段时间的方法,但我不太喜欢它。
首先,我从来没有想出一个好听的名字,除了将
testSupport
附加到原始模块的名称,这导致名称像core-testSupport
、persistence-testSupport
等等。其次,它创建了很多模块,项目树被这些模块污染了。
解决方案 2:(我希望得到反馈的那个)
configurations {
testSupportCompile.extendsFrom compile
testSupportRuntime.extendsFrom runtime
}
sourceSets {
testSupport {
compileClasspath += sourceSets.main.output + configurations.testSupportCompile
runtimeClasspath += compileClasspath + configurations.testSupportRuntime
}
}
task testSupportJar(type: Jar) {
from sourceSets.testSupport.output
classifier 'testSupport'
}
artifacts {
testSupportCompile testSupportJar
}
上面的 gradle 配置可以放在名为 testSupport.gradle
的文件中,并应用于需要此专用源集以提供可在测试中重复使用的 类 的任何模块。
定义依赖项将像这样工作:
testCompile project(path: ':core', configuration: 'testSupportCompile')
我对 gradle 还是个新手,研究了很多,但我仍然有几个问题。
我知道声明一个新的源集会自动创建两个配置:
<sourceSet>Compile
和<sourceSet>Runtime
。我不太喜欢这种方法的是,在声明依赖项时必须使用 testSupportCompile 配置。有没有办法将其别名为testSupport
或类似的别名?我的项目目前可以正常编译。但是,我不确定我是否以正确的方式做事。这个配置怎么改进?
是否有任何其他方法可以实现所需的功能?在研究过程中,我并没有真正找到关于这个主题的太多信息,这让我觉得我要么使用了错误的搜索词,要么做了一些根本不应该做的愚蠢事情。
我知道这是一个宽泛的问题,但我不确定除了此处之外,在哪里可以获得关于此类问题的适当反馈。
我有类似的情况,我已经推迟了一段时间的解决方案,使用了各种 hack 和解决方法。你的问题是调查它的最终动机。
这就是我最终得到的——EDIT 与 Thomas 合作完成的:
configurations {
// create a new configuration and inherit everything from compile
testlib.extendsFrom compile
}
sourceSets {
testlib {
// We will at least need access to our main sourceSet and all dependencies that are declared for our configuration.
compileClasspath += sourceSets.main.output + configurations.testlib
}
}
task testlibJar(type: Jar) {
from sourceSets.testlib.output
classifier 'testlib'
}
artifacts {
testlib testlibJar // include the classes into the new configuration
archives testlibJar // optional: include the support JAR into "uploadArchives", so it may also be used in other projects
}
然后,在依赖模块中,只需使用:
dependencies {
testCompile project(path: ':otherproject', configuration: 'testlib')
}
请注意,(空)testlibCompile
和 testlibRuntime
配置仍会创建(作为引入新 testlib
源集的结果),但我相信它是安全的无视他们。
另外,经常有项目自己的test
配置需要使用testlib
(项目测试依赖通用测试支持)。在这种情况下,您可以在同一项目的两个配置之间添加依赖关系:
testCompile project(path: ':myproject', configuration: 'testlib')
或单独增强编译和运行时类路径:
configurations {
testlib.extendsFrom compile
testCompile.extendsFrom testlib
}
sourceSets {
test {
compileClasspath += sourceSets.testlib.output
runtimeClasspath += sourceSets.testlib.output
}
}