Hi, guys. I recently upgraded to kotlin 1.8.0 and found that the new `androidInstrumentedTest` doesn...

# multiplatform

[SeikoDes]

Hi, guys. I recently upgraded to kotlin 1.8.0 and found that the new androidInstrumentedTest doesn’t dependsOn commonTest by default, is this a bug or desgin this?

[Sebastian Sellmair [JB]]

This is by design. Only ‘unitTest’ depends on commonTest by default.
Feel free to add this dependsOn edge again in your buildscript

kotlin {
    val commonTest by sourceSets.getting
    val androidInstrumentedTest by sourceSets.getting
   
    androidInstrumentedTest.dependsOn(commonTest)
 
}

[Paul Woitaschek]

What's the reason behind this?

[John O'Reilly]

some more background in https://kotlinlang.org/docs/whatsnew18.html#kotlin-multiplatform-a-new-android-source-set-layout

[Paul Woitaschek]

Where does this explain why androidInstrumentedTest doesn’t inherit commonTest?

[Sebastian Sellmair [JB]]

What’s the reason behind this?

Because previously unitTests and instrumentedTests declared a dependsOn edge to commonTest.
This certainly was not a good idea, since most projects either want to actualise a test from common as unit or instrumented test. The requirement to do it for both was bad.
So given that you cannot have them both depend on commonTest: There needs to be a default to be chosen.
Either instrumentedTests or unitTest or none will by default dependOn commonTest.
We decided to go with unitTest by default.

[Paul Woitaschek]

In our commonTest we have little actual expect things but also a lot of common test utils like factories etc. I find this to be a confusing default.

[Javier]

Same for me but I think it is the same behavior than applying dependencies in normal Android libraries. If you apply a bom in unit tests you need to apply it in integration tests too.

[Javier]

I think the real problem here is the lack of testFixtures source set

[Javier]

With it everything is solved as unit tests and integration tests (and custom ones like functional tests) would depend on those fixtures.

@Sebastian Sellmair [JB] will it be prioritized for 2023?

https://youtrack.jetbrains.com/issue/KTIJ-14843

[Sebastian Sellmair [JB]]

Good point about testFixtures. I like the argument here.
Its not prioritised directly: See; we are building APIs so that Google can fully maintain the Android multiplatform target on their end properly.
Once this APIs are ready, I am pretty sure Google will bring support for Android Multiplatform testFixtures!

Regarding your test utils:
How about creating new source set

kotlin {
    val commonTestUtils by sourceSets.creating
    val androidUnitTest by sourceSets.getting
    val androidInstrumentedTest by sourceSets.getting

   androidUnitTest.dependsOn(commonTestUtils)
   androidInstrumentedTest.dependsOn(commonTestUtils)
  // ...
}