Reading up on the experimental Compose UI tests at...

# multiplatform

[Brill]

Reading up on the experimental Compose UI tests at https://kotlinlang.org/docs/multiplatform/compose-test.html#what-s-next
I'm thinking we really need to separate unit test from Ui Tests. Does anyone know the thought on combining them?

[Oliver.O]

Aren't these orthogonal categories? Wouldn't you call a simple UI test a unit test? What's missing for you?

[Brill]

I guess you could say they were "orthogonal" categories of test in that they are at right angles to each other :)

I would say that a UI test is testing behaviour, while a unit test is testing a discrete/isolated unit of code.

I think there is a very big difference between the two, and that there is a fairly interesting philosophical discussion around the difference, but in our case there is a more practical difference.

Mainly that they run at different times. Also, UI tests need to run in the devices context, and unit tests don't (the difference between src/test and src/androidTest in a single platform project).

As for how I personally tend to use the two types of test: unit tests verify that my code does what I think it does, and UI tests verify that I have the acceptance criteria in the story correct. Both help me avoid regression.

[Oliver.O]

OK. Of course you can only run UI tests on targets that support the necessary infrastructure (like androidTest). Although you might also need to run (non-UI) unit tests on androidTest, like when you are checking hardware/OS interactions like sensors.

But you are free to structure your tests as you like, so what's missing in Compose UI tests?

[Brill]

Compose UI tests work fine, i use them all the time, I'm interested in the experimental framework linked above, and how it relates to KMP.

It looks like its coming, just not all that mature yet.

I was wondered what the thought was, on having them in the same source tree as the unit tests.

It makes them harder to isolate when I want to run the very speedy unit test, and not run the slow UI tests.

[Oliver.O]

OK, that's easy. You know Jetpack Compose tests with composeTestRule. Now we have Compose Multiplatform which is based on Jetpack Compose, but extended to other targets like desktop (JVM) and browsers (JS/Wasm). Its runComposeUiTest function provides basically the same functionality as composeTestRule, but as a this context, so its a bit less boilerplate. Those UI components that don't need Android-specific APIs can even be tested on desktops. And UI tests on desktops are fast, because now you don't need an emulator. Does that help?

[Oliver.O]

Also, Compose Multiplatform is not experimental. It is just the test API. In this context, experimental means that the API surface can change, not that its functionality is less stable.

[Oliver.O]

So it could be that having the tests in composeApp/src/commonTest/kotlin looks strange when you're coming from Android. That's because now your UI tests can cover multiple target platforms, Android being just one of them. And in this case, you'll put UI code in commonMain and UI tests in commonTest. On the Android side, you still have your separate directories for what's now called "host-side tests" (formerly unit tests) and "device-side tests" (formerly instrumented tests).