https://kotlinlang.org logo
Join Slack
Powered by
Anyone else having issue with wait on desktop test...
# compose-desktop
c
Anyone else having issue with wait on desktop tests? https://kotlinlang.slack.com/archives/C3PQML5NU/p1740154359781699
a
Sounds like it should have 
sleep
, at least on the desktop. But other than spinning the CPU unnecessarily, why does it matter? 
sleep
also blocks the thread.
c
Jake found the issue, android will sleep for 10ms where as desktop will block waiting for the frame indefintly
a
I read what Jake wrote
But again, sleep blocks the thread too.
c
Not sure, but that while loop sleeping works, when 
waitUntil
doesn't...
a
Copy code
@Test
    fun myTest() = runComposeUiTest {
        setContent {}

        waitUntil(
            timeoutMillis = 1_000,
            condition = { false }
        )
    }
fails after 1 second with
Copy code
Condition still not satisfied after 1000 ms
androidx.compose.ui.test.ComposeTimeoutException: Condition still not satisfied after 1000 ms
c
Sure
a
Copy code
var value = false
    @Test
    fun myTest() = runComposeUiTest {
        thread {
            Thread.sleep(1000)
            value = true
        }
        setContent {}

        waitUntil(
            timeoutMillis = 2_000,
            condition = { value }
        )
    }
passes after 1 second
c
yeah your tests are not complex enough, you need a suspending function running on the main dispatcher beeing called from the ui
a
A 
sleep
won’t solve that
c
Does here...
I can try and create an example when i got a minute
And again, works fine on Android Emulator
a
A reproducer would help, yes.
c
Looks like it's already assigned to you, not sure if its the cause, but maybe releated?
a
Are you using a custom effectContext in your Android test?
c
Don't believe so
a
Then I don’t see how it can be relevant
c
Another day, being told I'm wrong but still having to work around this bug
a
I’d love to help, but I need a reproducer to work with.
c
Copy code
// Let Android run measure, draw and in general any other async operations.
                Thread.sleep(10)
any other async operations.
Why is the desktop implementation different?
The issue is, @Alexander Maryanovsky is that gaslighting someone after them showing you multiple issues doesn't get us anywhere
After there are multiple people and tickets presenting this issue
a
Why is the desktop implementation different?
Because the implementation is allowed to be different, if the effect is the same. Many things are implemented differently in compose-multiplatform. The reason here specifically is that you’re not looking at desktop/JVM code, but pure Kotlin (multiplatform) code, and there’s no 
sleep
function in Kotlin. We could add an expect/actual and actually 
sleep
in the desktop implementation, if there’s a good reason to do so.
after them showing you multiple issues doesn’t get us anywhere
After there are multiple people and tickets presenting this issue
You have linked one unrelated issue here.
I don’t understand why you’re upset, really. I want to help you. Show me the problem so I can help you.
c
Because your gaslighting me: https://kotlinlang.slack.com/archives/C01D6HTPATV/p1740162039145959?thread_ts=1740157508.850439&cid=C01D6HTPATV You're telling someone they are wrong, despite having evidence to show otherwise, so my sleep to work around this bug doesn't work?
Despite it literally fixing this issue is multiple places in multiple code bases
I've been trying to distill a sample, but it looks like it might be a common->desktop isssue, I create the same code to share in the desktop source and it works, so it seems something odd when going across source sets
a
The only way 
sleep
would make a difference here is if what you’re waiting until happens in a thread with a much lower priority, and the scheduler never actually runs it. I don’t know if any JVMs have such a scheduler.
If 
sleep
does help you, you can use something like this:
Copy code
@OptIn(ExperimentalTestApi::class)
inline fun ComposeUiTest.waitUntilIdleWithSleep(
    conditionDescription: String? = null,
    timeoutMillis: Long,
    crossinline condition: () -> Boolean
) {
    waitUntil(
        conditionDescription,
        timeoutMillis,
        condition = {
            condition().also {
                Thread.sleep(10)
            }
        }
    )
}
c
I just upgraded to compose to 1.8-beta01, that seemed to fix all but one place, and the last remaining only fails on CI oddly (Ubuntu 22 GH runner, 8 core). Lemme try that method you posted see if that works instead
The much better news, is that before updating, waitFor would just hang forever, now it will at least fail with condition not met
a
Yes, there was a missing 
throw ComposeTimeoutException
there, which was fixed here
c
ahh nice
Interesting, still fails on CI, do desktop tests run differently on headless/ubuntu vs OSx? I thought they both use Skia under the hood?
3 Views
Open in Slack
PreviousNext
Powered by