Hi, I would like to know: If I have a KMP project ...

# compose-desktop

[gpaligot]

Hi, I would like to know: If I have a KMP project (for now, only Android and Desktop targets) and with shared compose components, there is any way to write composable tests in the common source set or I need to choose between Android and Desktop?

[darkmoon_uk]

Hi @gpaligot..
I'm most interested to understand what you mean by a Compose for Desktop test - assuming you mean actual UI tests of Compose for Desktop screens/components. That's something I've asked about a couple of times here and gained no answer. AFAIK there's no UI test running environment for Desktop.

[Ugi]

@gpaligot I have successfully run shared compose test both on android and desktop, but I couldn't get IDEA to properly analyze the code. In the end I decided that I'll use desktop UI tests in libraries and while developing and then invest in android/shared UI tests later. I think the analysis problem could be worked around with a bit of gradle sourceset hackery to run it as a jvm test sourceset in IDEA and as a shared sourceset when running gradle

[Ugi]

@darkmoon_uk This is my setup for compose tests more or less

val composeJUnit4 = "org.jetbrains.compose.ui:ui-test-junit4"
        val commonTest by getting {
            dependencies {
                implementation(compose(Deps.Common.Test.composeJUnit4))  {
                    exclude("net.java.dev.jna", "jna")
                }
            }
        }

And then in jvmTest or whatever your test source set is something like this

class PlaceholderTest {

    @get:Rule
    val composeTestRule = createComposeRule()

    @Test
    fun test() {
        var clicked = false
        composeTestRule.setContent {
            Button(onClick = {
                clicked = true
            }){
                Text("Hello")
            }
        }
        composeTestRule.onNodeWithText("Hello").performClick()
        assertTrue(clicked)

    }
}

[Ugi]

You don't havve to exclude jna, I had some other libraries that were clashing with it on android

[Ugi]

And this is where I found out about desktop tests https://github.com/JetBrains/compose-jb/issues/368#issuecomment-810033136

[darkmoon_uk]

Thank you @Ugi! This got me somewhere, but also reveals that Desktop UI testing is still in development.
For example; the JetBrains code still has a TODO() in place of performTextInput - of course this is a really fundamental method for testing most Apps, so the API is not so useful right now.

[darkmoon_uk]

The relevant issue is here

[darkmoon_uk]

I also learned quite quickly that it seems you are not expected to provide a Window into the testRule, it should be the content inside your window. It seems to place that inside a TestWindow for you.
I wonder if that limits some forms of testing? Already I have some layout logic that depends on the Window size, but not sure this design leaves us with a way to change the Test Window size from its default?

[Ugi]

I had the same question myself yesterday, and don't know the exact answer. I am luckily using my own local composite to pass window size to composable functions, so I can supply dimensions through that, but I am not too far into writing test to be sure that this won't break anything

[Ugi]

Although, now I am wondering if I need the window size at all, and if I can replace it just with BoxWithConstraints. I can't remember why I started using window size in the first place.

[darkmoon_uk]

FYI supplying a Window to testRule.setContent did not cause a crash, the content was presented but scaled very small and my test tags weren't found suggesting the whole semantic tree was being nested in some unintended way for the Test code. That led me to discover JBs use of TestWindow.

[Ugi]

Good to know, thanks!