Unit tests with JUnit and coroutines

A first JUnit test

JUnit is the standard testing framework for Kotlin and Java. The Android Studio template includes JUnit 4 for local tests. Each test is a function marked @Test; if an assertion fails, the test fails with a message showing what was expected and what actually happened.

// app/src/main/.../Pricing.kt
object Pricing {
    fun totalWithGst(subtotalPaise: Long, ratePercent: Int): Long =
        subtotalPaise + subtotalPaise * ratePercent / 100
}

// app/src/test/.../PricingTest.kt
import org.junit.Assert.assertEquals
import org.junit.Test

class PricingTest {
    @Test
    fun gstAt18PercentIsAdded() {
        assertEquals(118_000L, Pricing.totalWithGst(100_000L, 18))
    }

    @Test
    fun zeroSubtotalStaysZero() {
        assertEquals(0L, Pricing.totalWithGst(0L, 18))
    }
}

A useful pattern for every test is Arrange, Act, Assert: set up the data, do the action, check the result. Keep one behaviour per test so a failure points to exactly one problem.

Other useful assertions are assertTrue(condition), assertFalse(condition), assertNull(value) and assertNotNull(value). To check that code throws, use assertThrows (JUnit 4.13 and later) or try/catch with fail(). Many teams also use a small assertion library such as Truth for more readable checks, but plain JUnit is enough to start.

Tests for pure Kotlin code, code with no Android classes, are the easiest of all. This is another reason to keep business rules out of activities and composables: a function in a plain Kotlin object can be tested in milliseconds.

Testing a ViewModel with a fake

interface CartRepository {
    suspend fun priceOf(item: String): Int
}

class FakeCartRepository : CartRepository {
    override suspend fun priceOf(item: String) = when (item) { "chai" -> 15; else -> 40 }
}

class CartViewModel(private val repo: CartRepository) : ViewModel() {
    private val _total = MutableStateFlow(0)
    val total: StateFlow<Int> = _total.asStateFlow()
    fun add(item: String) = viewModelScope.launch { _total.update { it + repo.priceOf(item) } }
}

runTest and the Main dispatcher

viewModelScope uses Dispatchers.Main, which does not exist in a local JVM test. The kotlinx-coroutines-test library solves this: Dispatchers.setMain replaces Main with a test dispatcher, and runTest runs coroutine code in a test, skipping delays so tests stay fast. Many teams wrap the setMain/resetMain calls in a small reusable JUnit rule (often called MainDispatcherRule).

@OptIn(ExperimentalCoroutinesApi::class)
class CartViewModelTest {
    private val testDispatcher = UnconfinedTestDispatcher()

    @Before fun setUp() { Dispatchers.setMain(testDispatcher) }
    @After fun tearDown() { Dispatchers.resetMain() }

    @Test
    fun addingTwoChaisGivesThirty() = runTest {
        val vm = CartViewModel(FakeCartRepository())
        vm.add("chai")
        vm.add("chai")
        assertEquals(30, vm.total.value)
    }
}

Naming and organising

Name tests after behaviour, not methods: addingTwoChaisGivesThirty is clearer than testAdd. Some teams use backtick names in Kotlin tests, like `adding two chais gives thirty`, which JUnit on the JVM allows. Keep test files in the same package as the code they test, under src/test.

Common mistakes

• Swapping expected and actual in assertEquals, which makes failure messages confusing.
• Forgetting Dispatchers.setMain: "Module with the Main dispatcher is missing".
• Real delays in tests. runTest skips delay() with virtual time; do not use Thread.sleep.
• One giant test that checks ten things. Split it.