I have some Compose UI tests that need to read str...

# compose-desktop

[Carter]

I have some Compose UI tests that need to read string resources, to check that UI values match expected values. getString() is a suspend fun, while stringResource() is a @Composable fun.
runComposeUiTest doesn’t give us a Composable scope or a coroutine scope. So what’s the expected way to read resources in commonTest?

Do we nest runTest inside runComposeUiTest?

[Alexander Maryanovsky]

setContent to get a composable context

[Alexander Maryanovsky]

and runBlocking to get a suspending context

[Carter]

Sure, although setContent isn’t really appropriate for calling stringResource() for a test assertion.

Is runBlocking supported by all targets (e.g. JS)?

[Alexander Maryanovsky]

@Konstantin Tskhovrebov Do we have a blocking alternative?

[Konstantin Tskhovrebov]

no. because JS cannot be blocked.
there must be the async API only

[Carter]

What about nesting runTest?

[Axel Levy]

Hi, did you find a solution ? I have the similar use case that is blocking my wasmJs tests at the moment