https://kotlinlang.org logo
Title
s

s3rius

04/04/2023, 9:36 PM
Hey there @Arkadii Ivanov Have you put any thoughts into how 2.0.0's main thread checker ought to work with coroutine-test's setMain? I use
Dispatchers.setMain(StandardTestDispatcher())
in most of my tests, and this unsurprisingly triggers the MainThreadChecker. I'm working around it with a custom implementation:
class TestMainThreadChecker : MainThreadChecker {
    override fun isMainThread(): Boolean = Thread.currentThread().threadGroup.name.contains("main")
}
But aside from the fact that I'm not even sure this is correct, it sounds like a fairly annoying hurdle for adopters of Decompose.
a

Arkadii Ivanov

04/05/2023, 12:39 AM
Thanks for the info! That shouldn't be a crash, just an error log. So you can pretty much ignore it. Also, you should be able to disable the check by overriding the error handler.
MainThreadChecker
is an internal API, it shouldn't be used outside of the library.
Would you prefer the check to be opt-in rather than opt-out?
Also, I could add a dedicated API to disable main thread checks all together. So you could disable it in @BeforeTest.
s

s3rius

04/05/2023, 6:06 PM
Oh geez, I saw the stacktrace and immediately jumped to the conclusion it was the reason my tests were failing. You're right, it's just a log message! 🙄 Regarding its behavior... I like that it's opt-out for production code. Particularly since it's fairly easy to "slip" onto a non-UI thread in a coroutine world. For test scenarios such as mine I don't know. In theory I'd like to retain the thread check. I assume StandardTestDispatcher is still backed by only one thread, meaning the semantics stay the same. But in practice I don't know if this would work as expected.