Multi-Project Test Dependencies with Gradle

Multi-project test dependencies with gradle

Deprecated - For Gradle 5.6 and above use this answer.

In Project B, you just need to add a testCompile dependency:

dependencies {
  ...
  testCompile project(':A').sourceSets.test.output
}

Tested with Gradle 1.7.

Gradle test library in multi module project

Apparently this can be done by using the https://docs.gradle.org/current/userguide/java_testing.html#sec:java_test_fixtures

• they can see the main source set classes

• test sources can see the test fixtures classes

So changes to the example in the question are:

1. changing the src/test to src/testFixtures
2. declaring the dependency as testImplementation(testFixtures(project(":testlib")))
3. Adding java-test-fixtures plugin to the build.gradle.kts for the testlib module

Gradle multi-project only executes tests for one project

Default Gradle behavior is to stop if any task fails, and Gradle considers a failing test as failing the check task. As a consequence, if any test fails in a certain project, the tests for the projects that have not yet been executed will not get executed.

The --continue can be useful in this case, it changes the default behavior and forces Gradle to continue executing all tasks even if some of them failed.

In this issue it is very well explained https://youtrack.jetbrains.com/issue/KT-49858p

Gradle - add dependency to tests of another module

There's a couple of approaches solving the problem of importing test classes in this article. https://softnoise.wordpress.com/2014/09/07/gradle-sub-project-test-dependencies-in-multi-project-builds/ The one I used is:

code in shared module:

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

configurations {
    testOutput
}

artifacts {
    testOutput jarTest
}

code in module depending on the shared module:

dependencies{
testCompile project(path: ':common', configuration: 'testOutput')
}


And there seems to be a plugin for it as well! https://plugins.gradle.org/plugin/com.github.hauner.jarTest/1.0

How to add dependencies to tests of another project in a multi-platform multi-project Kotlin build

To establish a dependency of this sort between single-platform projects, you would normally need to create a Gradle Configuration in the producer project, add the test compilation outputs or a test JAR into that configuration, and, in the consumer project, depend on that configuration (i.e. add a project(...) dependency with an explicit configuration or, more preferrable, add attributes to ensure that Gradle chooses the test-outputs configuration in variant-aware dependency resolution).

However, all of this requires that tests are compiled to a form that could be reused by the consumer project's common source sets. With Kotlin Multiplatform projects, this is not yet the case. While the production common source sets, which participate in published compilations, are compiled to Kotlin metadata (*.kotlin_metadata files), test sources and other kinds of non-published code are not yet transformed to that format.

Instead, tests are currently only compiled to the final platform-specific binaries (i.e. *.class files, *.js, Native binaries), which cannot be used for common sources analysis.

Therefore, dependencies of this kind are not supported yet. This could change in the future. Please follow this issue in the Kotlin issue tracker: KT-35073.

Gradle multi-module tests falling

Not entirely certain but when I've had this sort of problem in the past its because I was trying to share classes from moduleA in moduleB... but as they're spring boot applications, they're packaged differently and this is impossible.

What I can say looking at the above is you've set the root project build.gradle to apply the plugin application. The root project will not be an application and subprojects are springboot applications, so this can be removed entirely. You're essentially specifying two lots of "mainClass" - one for the application plugin inherited from the root project, and another for the springboot application plugin - applied at root - but the :common project is not a springboot application.. so it needs pushing down the module hierarchy to the modules which are actually springboot applications, and not applied at the root where it will be inherited by all applications.

If you move the plugins to the relevant modules that need them, you'll find the build.graldes will become cleaner as you won't have to disable unused plugins in the sub-build.gradle definitions.

---

Related Topics