Thanks for the reply. Your channel has a very wide audience and many inexperienced watchers may think that using runBlocking in unit tests is a best practice, while it is not, unfortunately. So just thought it is worth mentioning that there is an alternative way designed specifically for the case.
@@eugenepopovich2264 the only real difference is that runTest skips delays, which is not often needed. Apart from that they behave pretty much the same. Also with runBlocking, you can use a test dispatcher
@@PhilippLacknerI would not agre. We had a lots of issues with flaky tests in our company's project. Switching back to runTests, resolved some of the flakines.
Another valid use case for `runBlocking` I have found is inside `Filter.performFiltering()` (if you are so unlucky and still have to use Adapters in your app). Just like the Okhttp interceptor example, `performFiltering()` is called on a different thread than main, so you can block it without freezing the UI.
When writing unit tests for code that involves suspending functions or coroutines, runBlocking helps you to create a structured way to run asynchronous code in a synchronous testing environment.
i normally only use them when I have to switch from suspend functions to some older rxJava stuff(assuming is non ui thread) and i don't have time to refactor
`runTest` should be used in unit tests which uses `TestScheduler` under the hood
Yes true thanks for adding! doesn't make a difference in the example I showed though
Thanks for the reply. Your channel has a very wide audience and many inexperienced watchers may think that using runBlocking in unit tests is a best practice, while it is not, unfortunately. So just thought it is worth mentioning that there is an alternative way designed specifically for the case.
@@eugenepopovich2264 the only real difference is that runTest skips delays, which is not often needed. Apart from that they behave pretty much the same. Also with runBlocking, you can use a test dispatcher
@@PhilippLacknerI would not agre. We had a lots of issues with flaky tests in our company's project. Switching back to runTests, resolved some of the flakines.
For tests, we should use runTests, since it uses testScheduler. Using runBlocking can lead to flaky tests.
Another valid use case for `runBlocking` I have found is inside `Filter.performFiltering()` (if you are so unlucky and still have to use Adapters in your app). Just like the Okhttp interceptor example, `performFiltering()` is called on a different thread than main, so you can block it without freezing the UI.
Ooooooo new thumbnail style! I like it!
Hey! Philipp you forget add this video to coroutines playlist 😅
When writing unit tests for code that involves suspending functions or coroutines, runBlocking helps you to create a structured way to run asynchronous code in a synchronous testing environment.
You forgot to mention that runBlocking can throw InterruptedException and may cause additional weird behavior (check open issues)
U always know what I need rn
i normally only use them when I have to switch from suspend functions to some older rxJava stuff(assuming is non ui thread) and i don't have time to refactor
Good video. Isn't runblocking also used for desktop main functions? I see it whenever I create a new project on Intellj
Can't I user CoroutineScope in interceptor?
helpful ......thank you
Please add a video about how i optimise my codes
Can u make videos on some random projects like u used to back then
❤❤❤❤❤🎉🎉🎉
On real project run blocking is not recommended only for testing
Yes, When we have a usecases if we want to test the Coroutines behaviour currently stop our current thread it will help us!!