Comments (3)
Yes, that's better, thanks.
For testing coroutines on Android, the recommended approach is to inject the scope: https://developer.android.com/kotlin/coroutines/test#inject-scope This way, you can use viewModelScope
in production, but during testing, pass backgroundScope
and have the work properly cancelled.
In the "setting the Main dispatcher" section, one-shot operations are shown, ones that perform some task and then finish. For testing such tasks, just setting the main dispatcher is fine. When a task in a viewModelScope
outlives the test, you need to cancel it somehow, and injecting the scope becomes mandatory.
The reason repro
hangs but noRepro
doesn't is that the test dispatcher always knows it still has extra things to do in the repro
case (that is, check every 300 ms for new elements), but in the noRepro
case, it sees that there is no more work to execute and finishes, even though some coroutines are still running and weren't cleaned up.
from kotlinx.coroutines.
Both of these tests are written incorrectly, because they break structured concurrency. Manually creating a CoroutineScope
, passing the dispatcher to it, can lead to various issues; in this case, the coroutine simply will leak without completing. For example, in CoroutineScope(dispatcher).launch { try { flow.collect { } } finally { println("cleaning up resources") } }
, the resources won't get cleaned up.
A correct test would be something like this:
@Test
fun noRepro() = runTest {
val flow = MutableSharedFlow<Int>()
backgroundScope.launch {
flow.collect {}
}
}
from kotlinx.coroutines.
Thank you for your reply @dkhalanskyjb. But if both tests are written incorrectly, shouldn't both of them hang? My concern is that there are probably plenty of Android ViewModel
tests that are being written incorrectly even though they are following the documentation for Testing Kotlin coroutines on Android, particularly the section Setting the Main dispatcher.
Here is a more realistic example that hopefully conveys what I am getting at:
class ReproViewModel : ViewModel() {
private val flow = MutableSharedFlow<Int>()
init {
viewModelScope.launch {
flow
.sample(300L) // Test on longer hangs if you comment out this line
.collect {}
}
}
}
class ReproTest {
// Normally this @Before/@After would be extracted out into a reusable JUnit rule.
@Before
fun setUp() {
Dispatchers.setMain(StandardTestDispatcher())
}
@After
fun tearDown() {
Dispatchers.resetMain()
}
@Test
fun repro() = runTest {
ReproViewModel()
}
}
from kotlinx.coroutines.
Related Issues (20)
- Provide an API to invoke a callback on job cancellation HOT 1
- Even After bumping kotlinx coroutine test dependency to 1.8.0 giving an UncaughtExceptionsBeforeTest. HOT 5
- ThreadLocal.asContextElement may not be cleaned up when used with Dispatchers.Main.immediate HOT 9
- `kotlinx.coroutines.debug`'s `module-info.java` is incorrect preventing any project using JPMS to use debug probes HOT 1
- BlockHound false positive in kotlin.jvm.internal.Reflection.renderLambdaToString HOT 3
- java.lang.NullPointerException: Cannot invoke "kotlinx.coroutines.flow.Flow.collect when bumping up coroutines 1.6.4 to 1.8.1 HOT 4
- Improve the API reference HOT 4
- Coroutine on EventLoop dispatcher fails to yield to a task which is resuming after a delay HOT 5
- TestScope swallows an exception thrown from `launch` outside `runTest` HOT 4
- Exceptions being swallowed during tests / UncaughtExceptionsBeforeTest HOT 6
- Flow collection silently hangs when dispatcher throws an exception
- Suggestion for a potential new Flow's `timeout` extension HOT 4
- Mutex is unlocked on cancellation HOT 2
- Crash on GraalVM at `1.9.0-RC` HOT 11
- Non-linearizable behavior in `cancel` + `awaitClose` inside of `produce` HOT 1
- Inherit from `kotlinx.coroutines` warning even with interface delegation ? HOT 1
- Consider stabilizing `CoroutineStart.ATOMIC` HOT 3
- 1.9.0-RC: `kotlinx-coroutines-core/jvm/src/internal/ProbesSupport.kt` calls ` kotlinx.coroutines.debug.internal.probeCoroutineResumed` HOT 1
- 1.9.0-RC: DispatchersToStringTest.testLimitedParallelism fails when CORE_POOL_SIZE == 2 HOT 3
- CancellableContinuation.invokeOnCancellation should accept a suspend callback HOT 16
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kotlinx.coroutines.