关于`test-support`代码的gradle配置的反馈

Question

我最近一直在考虑这个问题,并希望得到一些关于我几天前的想法的反馈.

问题:

在典型的代码库中,每个模块都有一个main和一个test源集.这可以在一段时间内很好地工作但是迟早我总是偶然发现我希望将一组类组合在一起的情况,这些类允许更容易地测试涉及特定模块的代码.一个很好的例子hamcrest是给定模块的一组匹配器类.

• 假设1:
  作为hamcrest测试代码的库,这些匹配器不应该进入main源集.

• 假设2:这些类也不应该进入test源集,因为对test源的依赖只是这些类可用的解决方法.人们通常不希望依赖于实际测试.它也建议不要(通过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')

我仍然有点新的研究和研究,但我仍然有一些问题.

1. 我知道声明一个新的源集会自动创建两个配置:<sourceSet>Compile和<sourceSet>Runtime.我不喜欢这种方法的是,在声明依赖时必须使用testSupport Compile配置.有没有办法将此别名testSupport或其他类似的别名？

2. 我的项目目前编译得很好.但是,我不确定我是否正确地做事.如何改进这种配置？

3. 有没有其他方法可以实现所需的功能？在研究的时候,我并没有真正发现这个话题,这让我觉得我要么使用错误的搜索术语,要么做一些不应该做的愚蠢的事情.

我知道这是一个广泛的问题,但我不知道在哪里得到适当的反馈,除了这里.

Answer 1

我遇到了类似的情况，并且我已经将解决​​方案推迟了一段时间，使用了各种技巧和解决方法。你的问题是调查它的最终动机。

这就是我最终得到的结果——与托马斯合作进行的 编辑：

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
    }
}