How do I get one module's test configuration to de...

# gradle

[dave08]

How do I get one module's test configuration to depend on another's test configuration in gradle kotlin dsl?

[Big Chungus]

dependencies {
  testImplementation(project(":another-module", configuration= "test")
}

[Big Chungus]

That's for dependencies, but once you can do the same for configurations too

[dave08]

I tried that...

[dave08]

Still doesn't see that dependency...

[dave08]

Using `

testImplementation(project(":domain", configuration = "test"))

`

[dave08]

is configuration= inside the project(...)?

[Big Chungus]

So did this work?

testImplementation(project(":domain", configuration = "test"))

[dave08]

No...

[dave08]

Intellij stills shows me like the screenshot.

[Big Chungus]

did you refresh gradle project?

[Big Chungus]

Are you sure the import is correct?

[Big Chungus]

is :domain module jvm-only or mpp?

[Big Chungus]

If it's mpp, then you need to use proper configuration name. e.g.: commonTest

[dave08]

jvm, I also refreshed the gradle project. The import is fine, I use the same for implementation (w/o the test configuration).

[Big Chungus]

try testImplementation(project(":domain", configuration = "testArtifacts"))

[dave08]

Could not resolve project :domain.

Required by:
project :data
> Project :data declares a dependency from configuration 'testImplementation' to configuration 'testArtifacts' which is not declared in the descriptor for project :domain.

[dave08]

It seems like the test configuration doesn't work exactly like the main one for some reason..

[Big Chungus]

how about testImplementation(project(path = ":domain", configuration = "testArtifacts"))

[Big Chungus]

or even testImplementation(project(path = ":domain", configuration = "testRuntimeClasspath"))

[Big Chungus]

https://softnoise.wordpress.com/2014/09/07/gradle-sub-project-test-dependencies-in-multi-project-builds/

[Big Chungus]

I think this should work

testImplementation(project(path = ":domain", configuration = "testImplementation"))

[christophsturm]

i think the cleanest way is to put your test helpers in a separate module. as a result you also have to put your tests in a separate module but actually i like that because then my tests also test that i have the visibility set correctly

[dave08]

testImplementation(project(":domain", configuration = "testImplementation"))

gives:
Could not resolve project :domain.
Required by:
project :data

[dave08]

I'd rather not have an extra module, since it's not common test deps, but rather tests fixtures from the domain tests that need to be used in the data layer's tests...

[dave08]

Thanks for that article @Big Chungus, in the end `

testImplementation(project(":domain").dependencyProject.sourceSets.test.get().output)

worked! Not so nice, but it works 🙈!

[Vampire]

Don't do that, that's unsafe error prone and prevents or disturbs some features

[Vampire]

If you want to share test fixtures, use the java-test-fixtures plugin: https://docs.gradle.org/current/userguide/userguide_single.html#sec:java_test_fixtures

[Vampire]

And a more general section about sharing outputs between projects: https://docs.gradle.org/current/userguide/userguide_single.html#cross_project_publications

[dave08]

Boy, for a "simple thing" gradle requires a bunch of setup and knowledge... thanks for the links, I guess I'll have to get to making that change sooner or later...

[Vampire]

Well, just use the java-test-fixtures plugin and it is simple.
It abstracts the complex attribute and variant stuff away to have it easily usable. 🙂

[dave08]

Yeah, I was kinda expecting to use the test variant itself, but it could clean up the variant if I separate all the fixture code out...

[Vampire]

There is no test variant and also no test configuration which is why some of the suggested things didn't work.
There is a test source set.
But there are by default no consumable configurations that other projects can resolve as those are not intended to be shared.
That's why you either if you don't want to publish it, can simply create a consumable configuration that other projects can safely resolve, or use the java-test-fixtures plugin that does it for you in a high-level way nicely where you then can separate the exact things you want to share with other projects as you usually don't want to share the actual tests with other projects.