Multi-project test dependencies with gradle

Making Project A's test output a testCompile dependency for Project B

For older Gradle versions, define testArtifacts in Project A's build.gradle to share its test outputs:

// In Project A's build.gradle
configurations {
    testArtifacts  // Sharing is caring, right? 😃
}

task testJar(type: Jar) {
    classifier = 'tests'
    from sourceSets.test.output
}

artifacts {
    testArtifacts testJar  // Packing my tests for you 😅
}


Then, in Project B, reference this testArtifacts configuration:

// In Project B's build.gradle
dependencies {
    // Project B saying: 'Thanks, I'll take that from you 👍'
    testCompile project(path: ':ProjectA', configuration: 'testArtifacts')
}


Important: apply the java plugin in Project B to ensure proper compilation and dependency resolution.

Sharing test resources in multi-project builds

In a multi-project set-up, create a separate source set for Project A if it contains substantial test classes or resources:

// In the shared test project
apply plugin: 'java'

sourceSets {
    test {
        java.srcDir 'src/test-shared/java' // My test scripts reside here 📚
        resources.srcDir 'src/test-shared/resources' // More resources for you! 📙
    }
}

// In Project B's build.gradle
dependencies {
    // Project B saying: 'I love using what you've shared 🥰'
    testCompile project(':BaseTesting').sourceSets.test.output
}


Good practices for advanced gradle configurations

In complex cases where direct task dependencies or custom JAR creation is needed, remember to keep things simple and clearly defined.

Ensuring task dependencies

To compile Project B only after Project A's tests are compiled, add a dependency on the task:

// In Project B's build.gradle
compileTestJava {
    // Compile only when A has finished. That's polite, isn't it? 😊
    dependsOn tasks.getByPath(':ProjectA:compileTestJava')
}


Creating a custom JAR for test classes

If you need a custom JAR for Project A's test classes:

// In Project A's build.gradle
task testJar(type: Jar) {
    // Pack only test outputs and avoid any extra baggage 😉
    from sourceSets.test.output
    classifier = 'test'
}

artifacts {
    archives testJar // Voila, your custom JAR is ready! 🏺
}


Then, reference this JAR as a dependency in Project B:

// In Project B's build.gradle
dependencies {
    // Project B saying: 'Who doesn't love custom JARs? 🎁'
    testCompile project(':ProjectA').tasks.testJar.outputs.files
}


Best practices and common pitfalls

Ensuring compatibility

Before kicking off, ensure compatibility among varying Gradle versions. You may resolve potential incompatibilities with conditional statements.

if (GradleVersion.current() < GradleVersion.version("5.6")) {
    // This compatibility check goes out to all the old-timers out there! 🎩
}


Organizing source sets

Avoid mixing the main and test classes. Use testFixtures to maintain a neat separation.

sourceSets {
    main {
        java.srcDirs = ['src/main/java']
        resources.srcDirs = ['src/main/resources']
    }
    testFixtures {
        // Don't mix them up! Party in the testFixtures section only 🥳
        java.srcDirs = ['src/testFixtures/java']
        resources.srcDirs = ['src/testFixtures/resources']
    }
}


Catering to multi-language projects

Multi-language setups may require you to ensure proper cross-language test support.

sourceSets {
    test.java.srcDir 'src/test/kotlin'
    test.kotlin.srcDir 'src/test/kotlin'    
    // Co-existing peacefully, just like at the UN ☮️
}
