Access to TestScope.backgroundScope
See original GitHub issueCoroutines 1.6.4 introduces TestScope.backgroundScope
.
Unfortunately, kotest only takes coroutineContext
from TestScope, it does not expose TestScope anywhere, making new backgroundScope
inaccessible.
Could this be exposed somewhere?
Issue Analytics
- State:
- Created a year ago
- Comments:7 (3 by maintainers)
Top Results From Across the Web
TestScope - Kotlin
A coroutine scope that for launching test coroutines. The scope provides the following functionality: ... The usual way to access a TestScope is...
Read more >Support testing coroutines that outlive the test #3287 - GitHub
Some test-specific API. For example, TestScope could provide access to some child scope in which all tasks are ignored when checking for leaks....
Read more >Testing Kotlin coroutines on Android
Inside runTest , you can access the testScheduler property of the TestScope and pass it in to any newly created TestDispatchers .
Read more >Change log for kotlinx.coroutines
Change log for kotlinx.coroutines. Version 1.6.4. Added TestScope.backgroundScope for launching coroutines that perform work in the background and need to ...
Read more >Unit Testing with Kotlin Coroutines: The Android Way - Medium
Test LiveData using InstantTaskExecutorRule ... That's because LiveData is a part of the Android lifecycle, and it needs to access the main looper ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Ideal thing from the user’s perspective would be kotest’s TestScope extending coroutines’s TestScope. That way user gets all top-level extensions (such as
runCurrent
andadvanceTime
) and direct access to all current and future TestScope features (such as backgroundScope) automatically and since it would be the receiver, using them would be very ergonomical.But I understand that actually implementing that would be messy, especially since
coroutineTestScope
can be turned off. Maybe it would be implemented even whencoroutineTestScope
is disabled, but all its methods would throw exception that they are not supported when disabled?Yeah I saw that in your PR after I typed that comment out.