Desktop testing setup

When the #androiddevs transitioned from Rx to coroutines the topic of testing didn’t get as much attention in this new world of concurrency.

It didn’t help that there was a seismic change in Kotlin’s testing apis with 1.6.0. A whole bunch of online resources and tutorials are now defunct courtesy this change1.

My journey in the matter started because I simply couldn’t understand why test apis like advanceTimeBy wouldn’t work reliably for me. The name made sense… but my time wasn’t being advanced in any meaningful way.

Then there’s the issue of flaky tests. Here’s an example:

Example of a failing test with advanceTimeBy
flaky test code on github

Run each test individually and it will pass; run them together as one test suite and test2 alone will fail. test1 passes but it takes a full 3s to run the test. If I have 300 of these in my app, are my tests going to take 15 minutes to run?

I needed to understand many core concepts in order to confidently explain all the above phenomena. I’d like to share my learnings from going down the rabbit hole, in this series of posts:

This is part of a series of posts on Coroutine Testing: ←

  1. Picking the right Dispatcher
  2. Never ending tests & backgroundscope
  3. Controlling time
  4. Helpful @Junit TestRule extension (coming soon)
  5. Full USF example for Android (coming soon)

  1. If you’re looking for the most current and useful resources on coroutine testing today:

    1. Untangling Coroutine Testing - Marton Braun
    2. jetbrains official docs
    3. developer.android.com docs
    4. 1.6.0 Coroutines test migration guide
     ↩︎