[Coroutine] 코틀린 코루틴 테스트

 💡 코틀린 코루틴에서 테스트하는 방법에 대하여 학습하였습니다.

 

코틀린 코투린 테스트

• 대부분의 경우 중단 함수를 테스트하는 것은 일반적인 함수를 테스트하는 것과 다르지 않습니다.

class FetchUserUseCase(
    private val repo: UserDataRepository
) {
    suspend fun fetchUserData(): User = coroutineScope {
        val name = async { repo.getName() }
        val friends = ascycn { repo.getFriends() }
        val profile async { repo.getProfile() }
        User(
            name = name.await(),
            friends = friends.await(),
            profile profile.await()
        )
    }
}

@Test
class FetchUserDataTest{
    // given 
    val repo = FakeUserDataRepository()
    val useCase = FetchUserUseCase(repo)

    // when
    val result = useCase.fetchUserData()

    // then
    val expectedUser = User(
        name = "Ben",
        friends = listOf(Friend("friend-id-1:")),
        profile = Profile("description")
    )

    assertEquals(expectedUser, result)
}

class FakeUserDataRepository : UserDataRepository

• 가짜 클래스와 간단한 어설션을 사용해 원하는 데이터가 들어와있는지 확인합니다.
• 목 객체 대신 가짜 클래스를 사용하는 것은 외부 라이브러리에 의존하지 않기 위함입니다.

시간 의존성 테스트 (StandardTestDispatcher)

suspend fun produceCurrentUserSeq(): User {
    val profile = repo.getProfile()
    val friends = repo.getFriends()
    return User(profie, friends)
} // 순차적 생성 

suspend fun produceCurrentUserSym(): User = coroutineScope {
    val profile = async { repo.getProfile() }
    val friends = async { repo.getFriends() }
    User(profile.await(), firends.await())
} // 동시에 생성

• 첫 번째 함수는 2초, 두번째 함수는 1초가 걸리게 됩니다.
• 두 함수의 차이를 어떻게 테스트할 지 생각해볼 수 있습니다.

class FakeDelayedUserDataRepository : UserDataRepository // 딜레이를 주는 함수

• 실제로 테스트에 딜레이를 줘서 시간을 줄일 수 있지만, 테스트 전체를 수행하는 시간을 증가시키게 됩니다.
• 이를 해결하기 위해서 kotlinx-coroutines-test 라이브러리에서 제공하는 StandardTestDispatcher를 사용할 수 있습니다.

TestCoroutineScheduler와 StandardTestDispatcher

• TestCoroutineScheduler는 delay를 가상 시간 동안 실행하여 실제 시간이 흘러간 상황과 동일하게 작동하기 때문에 정해진 시간만큼 기다리지 않도록 변경할 수 있습니다.
• StandardTestDispatcher는 다른 디스패처와 달리 코루틴이 실행되어야 할 스레드를 결정할 때만 사용되는 것은 아니며, 테스트 디스패처로 시작된 코루틴은 가상 시간만큼 진행되기 전까지 실행되지 않습니다.
• 실제 시간처럼 작동하는 가상 시간이 흐르게 하여, 그 시간 동안 호출될 모든 작업을 실행하는 advanceUntilIdle을 사용합니다.

fun main() {
    val scheduler = TestCoroutineScheduler()
    val testDispatcher = StandardTestDispatcher(scheduler)

    CoroutineScope(testDispatcher).launch {
        println("task1")
        delay(1000)
        println("task2")
        delay(1000)
        println("done")
    }

    println() // scheduer.currentTime Before
    scheduler.advanceUntilIdle()
    println() // scheduer.currentTime After
}
// [0] Before
// task1
// task2
// done
// [2000] After

• 기본적으로 StandardTestDispatcher는 TestCoroutineScheduler를 만들기 때문에 명시적으로 만들지 않아도 됩니다.
• StandardTestDispatcher는 직접 시간을 흐르게 하지 않으며, advanceUntilIdle를 실행해서 StandardTestDispatcher를 명시하지 않으면 코루틴이 재개되지 않습니다.
  • 이는 코드가 영원히 실행됨을 의미합니다.

advanceTimeBy

• advanceUntilIdle처럼 시간을 흐르게하는 또다른 방법이며, advanceTimeBy에 일정 밀리초를 인자로 넣어 활용할 수 있습니다.
• advanceTimeBy는 시간을 흐르게 하고 그동안 일어났을 모든 연산을 수행합니다.
• runCurrent 함수를 추가로 사용하여 정확히 일치하는 시간에 예정된 연산을 재개할 수 있습니다.

val testDispatcher = StandardTestDispatcher()

CoroutineScope(testDispatcher).launch // task1 
CoroutineScope(testDispatcher).launch // task2 

testDispatcher.scheduler.advanceTimeBy(2) // task1 수행 
testDispatcher.scheduler.runCurrent() // task2 수행

가상 시간이 작동하는 방법

• delay가 호출되면 디스패처가 Delay 인터페이스를 구현했는지 확인하고, 실제 시간만큼 기다리는 DefaultDelay 대신 디스패처가 가진 scheduleResumeAfterDelay 함수를 호출합니다.
• 가상 시간은 실제 시간과 무관하게 동작하며, Thread.sleep은 StandardTestDispatcher의 코루틴에 영향을 주지 않습니다.

advanceUntilIdle

• 몇 밀리초 이내의 가상 시간만 흐르게하여 코루틴 연산을 실행 가능하게 하는 함수입니다.

val dispatcher = StandardTestDispathcer()

CoroutineScope(dispatcher).launch {
    delay(1000)
    println("Done")
}

Thread.sleep(Random.nextLong(2000))
// 여기서 얼마나 기다리는지 상관 없이 결과에 영향을 주지 않습니다.

println("${dispatcher.scheduler.currentTime} Before")
dispatcher.scheduler.advanceUntilIdle() // advanceUntilIdle활용
println("${dispatcher.scheduler.currentTime} After")

// [0] Before
// Done
// [1000] After

TestScope

• 스코프만으로 해당 함수와 프로퍼터를 사용할 수 있는 스코프입니다.
• StandardTestDispatcher와 같은 역할을 수행하며, CoroutineExceptionHandler로 모든 예외를 모을 수 있습니다.

val scope = TestScope()
scope.launch {
    delay(1000)
}
scope.advanceTimeBy(1000)
scope.runCurrent()
scope.advanceUntilIdle()
// StandardTestDispatcher의 함수를 똑같이 사용할 수 있습니다

• 안드로이드 뷰 모델, 프레젠터, 프래그먼트를 테스트할 때 StandardTestDispatcher를 자주 사용합니다.
• 테스트 디스패처를 사용해 produceCurrentUseSeq와 produceCurrentUserSym 함수를 코루틴에서 시작하고, 유휴 상태가 될 때까지 시간을 흐라게할 수 있습니다.
  • [유휴 상태] : 컴퓨터 시스템이 사용 가능한 상태이나 실제적인 작업이 없는 시간
  • 얼마나 시간이 많이 흘렀는지 확인하는 방식으로 테스트할 수 있습니다.
  • 하지만 이러한 설계는 복잡하기 때문에 runTest를 주로 활용합니다.

runTest

• kotlinx-coroutines-test의 함수들 중 가장 흔하게 사용됩니다.
• TestScope에서 코루틴을 시작하고 즉시 유휴 상태가 될 때까지 시간을 흐르게 할 수 있습니다.
• TestScope + advanceUntilIdle()가 합쳐진 기능을하며, runBlocking()과 같은 동작을 합니다.
• 코루틴에서 시간이 얼마나 흘렀는지 확인할 수 있으며, 테스트하는 데 몇 밀리초만 소모합니다.

class Test{
    @Test
    fun test1() = runTest {
        assertEquals(0, currentTime)
        coroutineScope {
            launch { delay(1000) }
            launch { delay(1500) }
            launch { delay(2000) }
        }
        assertEquals(2000, currentTime)
    }
}

• runTest를 사용하면 가짜 저장소의 각 함수를 매우 빠르게 처리할 수 있습니다.
• 또한 가상 시간을 활용하기 때문에 테스트는 즉시 끝나게 되며, 정확한 currentTime 값을 얻을 수 있습니다.

@Test
fun `Should produce user sequentially`() = runTest {
    // given 
    val userDataRepository = FakeDelayUserDataRepository()
    val userCase = ProduceUserUseCase(userDataRepository)

    // when
    useCase.produceCurrentUserSeq()

    //then
    assertEquals(2000, currentTime)
}

• runTest와 다른 시간 의존성 테스트와의 관계는 아래와 같습니다.

백그라운드 스코프

• runTest 함수는 다른 함수처럼 스코프를 만들며, 자식 코루틴이 끝날 때까지 기다립니다.
• 절대 끝나지 않는 프로세스를 시작한다면 테스트 또한 종료되지 않습니다.

@Test
fun `should increment counter`() = runTest {
    var i = 0
    launch {
        while (true) {
            delay(1000)
            i++
        }
    }
    delay(1001)
    assertEquals(1,i)
    delay(1000)
    assertEquals(2,i)
    // coroutineContext.job.cancelChilderen()을 추가하면 테스트가 통과합니다.
    // 현재 코드로는 테스트가 종료되지 않습니다...
}

backgroundScope

• 이런 경우를 해결하기 위해서 runTest에서는 backgroundScope를 제공합니다.
• 이 또한 가상 시간을 지원하지만, runTest가 스코프 종료를 기다리지 않습니다.

backgroundScope.launch {
    // 위 코드와 동일한 내용입니다
}

취소와 컨텍스트 전달 테스트

• 특정 함수가 구조화된 동시성을 지키는지 테스트하려면 아래와 같은 가장 쉬운 방법이 있습니다.
  • 중단 함수로부터 컨텍스트를 받은 뒤 컨텍스트가 기대한 값을 가지고 있는지 확인
  • 중단 함수로부터 컨텍스트를 받은 뒤 잡이 적절한 상태인지 확인

suspend fun <T, R> Iterable<T>.mapAsync(
    transformation: suspend (T) -> R
): List<R> = coroutineScope {
    this@mapAsync.map { async { transformation(it) } }
        .awaitAll()
}

• 위 함수는 순서를 보장하면서 비동기적으로 원소를 매핑합니다.
• 아래와 같이 테스트해볼 수 있습니다.

@Test
fun `sould map async and keep elements order`() = runTest {
    val transforms = listOf(
        suspend { delay(3000); "A" } ,
        suspend { delay(2000); "B" } ,
        suspend { delay(4000); "C" } ,
        suspend { delay(1000); "D" } ,
    )

    val res = transforms.mapAsync { it() }
    assertEquals(listOf("A","B","C","D"), res)
    assertEquals(4000, currentTime)
}

• 위 테스트는 구조화된 동시성을 지키는 중단 함수가 정확하게 구현되었다고 보기는 어려우며 이유는 아래와 같습니다.
  • 부모 코루틴과 같은 컨텍스트를 사용하는지 확인하지 않음
  • 취소 상황을 확인하지 않음

부모 코루틴과 같은 컨텍스트를 사용하는지 테스트

• 부모 코루틴에서 CoroutineName과 같은 특정 컨텍스트를 명시하여 transformation 함수에서 그대로인지 확인하는 방법을 사용합니다.
• 중단 함수에서 컨텍스트를 확인하려면 currentCoroutineContext 함수나 coroutineContext 프로퍼티를 사용할 수 있습니다.

// in runTest
val ctx: CoroutineContext? = null
val name = CoroutineName("Name")
withContext(name) {
    listOf("A").mapAsync {
        ctx = currentCoroutineContext()
        it
    }
    assertEquals(name, ctx?.get(CoroutineName))
}

취소 상황을 확인

• 취소를 확인하는 방법은 아래의 순서로 진행됩니다.
  • 내부 함수에서 잡을 참조합니다.
  • 외부 코루틴에서 코루틴을 취소합니다.
  • 참조된 잡이 취소된 것을 확인합니다.

// in runTest
val job: Job? = null
val parentJob = launch { // 내부 함수에서 잡 참조 
    listOf("A").mapAsync {
        job = currentCoroutineContext().job
        delay(Long.MAX_VALUE)
    }
}
delay(1000)
parentJob.cancel() // 외부 코루틴 취소 
assertEquals(true, job?.isCancelled) // 참조된 잡이 취소된 것을 확인

테스트에 통과하지 못하는 경우

• 대부분의 애플리케이션에서는 위와 같은 테스트가 필요하지 않지만, 라이브러리에서는 활용됩니다.
• 만약 async를 외부 스코프에서 실행했다면 위 테스트에서는 실패합니다.
  • 구조화된 동시성을 지키지 못하는 경우

suspend fun <T,R> Iterable<T>.mapAsync(
    transformation: suspend (T) -> R
): List<R> =
    this@mapAsync
        .map { GlobalScope.async { transformation(it) } }
        .awaitAll()

UnconfinedTestDisptcher

• StandardTestDispatcher와 비슷한 기능을 하는 UnconfinedTestDisptcher 디스패처가 있습니다.
• StandardTestDispatcher와의 차이점은 StandardTestDispatcher는 스케쥴러를 사용하기 전까지 어떤 연산도 수행하지 않습니다.
• UnconfinedTestDisptcher는 코루틴을 시작했을 때 첫 번째 지연이 일어나기 전까지 모든 연산을 즉시 수행합니다.

fun main() {
    CoroutineScope(StandardTestDispatcher()).launch {
        print("A")
        delay(1)
        print("B")
    }
    CoroutineScope(UnconfinedTestDisptcher()).launch {
        print("C")
        delay(1)
        print("D")
    }
}
// 즉시 수행하므로, C를 가장 먼저 출력 
// C

• 아래와 같이 runTest에 이식해서 사용할 수 있습니다.

@Test
fun testName() = runTest(UnconfinedTestDisptcher())

목(mock) 사용하기

• 모킹 라이브러리를 활용하면 모든 테스트가 사용하는 저장소의 인터페이스를 바꾸는 상황을 피할 수 있고, 일부 클래스만 수정하여 이를 해결할 수 있습니다.

@Test
fun `should load data concurrently`() = runTest {
    //given
    val userRepo = mockk<UserDataRepository>()
    coEvery { userRepo.getName() } coAnswers {
        delay(600)
        someFriends
    }
    val useCase = FetchUserUseCase(userRepo)

    // when
    useCase.fetchUserData()

    // then
    assertEquals(800, currentTime)
}

디스패처를 바꾸는 함수 테스트

• 일반적으로 블로킹 호출이 많다면 Dispatchers.IO(or 커스텀 디스패처)를 호출하고, CPU 잡약적인 호출이 많다면 Dispatchers.Default를 호출합니다.
• 두 경우 모두 동시에 실행될 필요가 거의 없고 runBlocking을 사용해 테스트할 수 있습니다.
• 하지만 함수가 실제로 디스패처를 바꾸는 경우는 어떻게 확인할 수 있을지 생각해봐야 합니다.
  • 호출하는 함수를 모킹하여, 사용한 스레드의 이름을 가지고 오는 방법으로 확인할 수 있습니다.

@Test
fun `should change dispatcher`() = runBlocking {
    // given
    val csvReader = mockk<CsvReader>()
    val startThreadName = "MyName"
    val userThreadName: String? = null
    every {
        scvReader.readCsvBlocking(
            aFileName,
            GameState::class.java
        )
    } coAnswers {
        usedThreadName = Thread.currentThread().name
        aGameState
    }

    val saveReader = SaveReader(scvReader)

    //when
    withContext(newSingleThreadContext(startThreadName)) {
        saveReader.readSvae(aFileName)
    }

    //then
    assertNotNull(usedThreadName)
    val expectedPrefix = "DefaultDispatcher-worker-"
    assert(usedThreadName!!.startsWith(expetedPrefix))
}

함수 실행 중에 일어나는 일 테스트

• 아래와 같이 실행 중에 프로그레스 바를 보여주고 숨기는 함수를 작성하였습니다.

suspend fun sendUserData() {
    val userData = database.getUserData()
    progressBarVisible.value = true
    userRepository.sendUserData(userData)
    progressBarVisible.value = false
}

• 최종 결과는 결국 false 로 전환되므로, 실제 프로그레스 바의 상태가 변경되었는지 확인할 수 없습니다.
• 이런 경우 함수를 새로운 코루틴에서 시작하고 바깥에서 가상 시간을 조절하는 방법을 사용합니다.

runTest 활용

• runTest는 코루틴의 디스패처로 StandardTestDispatcher를 지정하며 대기 상태가 될 때까지 시간이 흐르게 합니다.
  • advanceUntilIdle 함수를 사용
• 자식 코루틴의 시간은 부모가 자식을 기다리기 시작했을 때 (함수 본체의 실행을 끝냈을 때) 흐르게 됩니다.
  • 그 이전에는 가상 시간을 조절할 수 있음

@Test
fun `should show progress bar when sending data`() =
    runTest {
        val database = FakeDatabase()
        val vm = UserViewModel(database)
        launch {
            vm.showUserData()
        }

        // then
        assertEquals(false, vm.progressBarVisible.valule)
        delay(1000)
        assertEquals(true, vm.progressBarVisible.valule)
        delay(1000)
        assertEquals(false, vm.progressBarVisible.valule)
    }

• 이 때 delay보다는 advanceTimeBy와 같은 명시적인 함수를 사용하는 방법이 가독성이 좋을 수 있습니다.

새로운 코루틴을 시작하는 함수 테스트

• 백엔드에서는 프레임워크에서 주로 코루틴이 시작되지만, 직접 만든 스코프 내부에서 코루틴을 시작할 때도 있습니다.

@Scheduled(fixedRate = 5000)
fun sendNotifications() {
    notificationsScope.launch {
        val notifications = notificationsRepository
            .notificationsToSend()
        for (notification in notifications) {
            launch {
                notificationService.send(notification)
                notificationRepository
                    .markAsSent(notification.id)
            }
        }
    }

• sendNotifications() 함수에서 알림이 실제로 동시에 전송하는지 테스트하고자 합니다.
• 단위 테스트에서 스코프의 일부로 StandardTestDispatcher를 사용할 수 있으며, send와 markAsSent 사이에 약간의 지연이 생기도록 수행하였습니다.
  • advanceUntilIdle, sendNotifications은 일반 함수이기 때문에 runBlocking을 사용하지 않았습니다!

@Test
fun testSendNotifications() {
    // given
    val notifications = List(100) { Notification(it) }
    val repo = FakeNotificationsRepository(
        delayMillis = 200,
        notifications = notifications
    )
    val service = FakeNotifictaionsService(
        delayMillis = 300,
    )
    val testScope = TestScope()
    val sender = NotificationSender(
        notificationsRepository = repo,
        notificationService = service,
        notificationScope = testScope
    )

    // when
    sender.sendNotifications()
    testScope.advanceUntilIdle()

    // 모든 알림이 보내지고 전송 완료 표시
    assertEquals(
        notifications.toSet(),
        service.notificationsSent.toSet()
    )

    assertEquals(
        notifications.map { it.id }.toSet(),
        repo.notificationsMarkedAsSent.toSet()
    )

    // 알림이 병렬로 전송
    assertEquals(700, testScope.currentTime)
}

메인 디스패처 교체

• 단위 테스트에는 메인 함수가 없으므로 메인 함수를 사용하려 하면, 테스트에서 메인 디스패처를 가진 모듈이 없다는 예외를 던집니다.
• 매번 메인 스레드를 주입하는 건 비용이 많이 들기 때문에 kotlinx-coroutines-test 라이브러리에서 Dispatchers에 setMain 확장 함수를 제공합니다.
• 모든 단위 테스트에 의해 확장되는 기본 클래스의 setup 함수(@Before or @BeforEach가 붙은 함수)에서 메인 함수를 설정해야하는 경우가 많습니다.
• 이러한 경우 코루틴이 Dispatchers.Main에서 항상 실행된다는 것이 보장됩니다.

@Test
fun settingMainDispatcher() = runTest {
    val testDispatcher = UnconfinedTestDispatcher(testScheduler)
    Dispatchers.setMain(testDispatcher)
}

코루틴을 시작하는 안드로이드 함수 테스트

• 안드로이드의 경우 코루틴이 ViewModel, Presenters, Fragments, Activities에서 주로 시작됩니다.
• 이 클래스들은 매우 중요하므로 테스트를 반드시 수행해야 합니다.
  • 어떤 스코프를 사용했는지는 중요하지 않으며, 코루틴을 시작하는 모든 클래스에서 했던 것처럼 스코프를 StandardTestDispathcer로 사용할 수 있습니다.
  • 의존성을 주입할 필요 없이, Dispatchers.setMain 함수를 사용해서 편하게 구현할 수 있습니다.

private val testDispatcher = StandardTestDispathcer()

@Before
fun setUp() {
    testDispatcher = StandardTestDispathcer()
    Dispatchers.setMain(testDispatcher)
}

@After
fun down() {
    DiDispatchers.resetMain()
}

• 위와 같이 디스패처를 생성하면 onCreate 코루틴은 testDispatcher에서 실행되므로 시간을 조작하는 것이 가능합니다.
  • 이 때  advanceUntilIdle()를 사용할 수 있습니다.

private lateinit var scsheduler : TestCorouitneScheduler

@BeforeEach
fun setUp() {
    scheduler = TestCoroutineScheduler()
}

@Test
fun `should show user name and sorteed news`() {
    //when
    viewModel.onCreate()
    scheduler.advanceUntilIdle()
}

룰이 존재하는 테스트 디스패처 설정

• JUnit4는 룰 클래스의 사용을 허용합니다.

룰

• 테스트 클래스의 수명 동안 반드시 실행되어야 할 로직을 포함하는 클래스
• 모든 테스트가 시작되기 전과 끝난 뒤에 실행해야 할 것들을 정의할 수 있씁니다.
• 테스트 디스패처를 설정하고 나중에 이를 해제해야 합니다.

룰 구현

• starting()과 finished()와 같은 수명 주기 메서드를 제공하는 TestWatcher를 확장할 수 있습니다.
• 룰은 TestCoroutineScheduler와 TestDispatcher로 구성됩니다.
• 룰을 사용한 클래스의 각 테스트가 시작되기 전에 TestDispatcher가 메인 디스패처로 설정되며, 각 테스트가 끝난 뒤에 메인 디스패처는 원래 상태로 돌아오게 됩니다.
• 스케줄러는 위 룰의 scheduler 프로퍼티로 접근할 수 있습니다.

Junit4의 룰

class MainCoroutineRule : TestWathcer() {
    lateinit var scheduler: TestCoroutineScheduler
        private set
    lateinit var dispatcher: TestDispatcher
        private set

    override fun starting(description: Description) {
        scheduler = TestCoroutineScheduler()
        dispatcher = StandardTestDispatcher(scheduler)
        Dispatchers.setMain(dispatcher)
    }

    override fun finished(description: Description) {
        Dispatchers.resetMain()
    }
}

룰 사용

class MainViewModelTests {
    @get: Rule
    var mainCorotineRule = MainCoroutineRule()

    // ...

    @Test
    fun `should show user name and sorted news`() {
        // when
        viewModel.onCreate()
        mainCorotuineRule.scheduler.advanceUntilIdle()


        // then
        assertEquals(aName, viewModel.userName.value)
        val someNewsSorted =
            listOf(News(data1), News(data2), News(data3))
        assertEquals(someNewSorted, viewModel,news.value)
    }
}

• MainCoroutineRule에서 advanceUntilIdle, advanceTimeBy, runCurrent, currentTime을 직접 호출하고 싶다면, 확장 함수와 프로터티로 정의할 수 있습니다.
• 이러한 방식은 안드로이드에서 코틀린 코루틴을 테스트할 때 자주 사용하며, JUnit5의 방식에서도 확장 클래스를 정의한다는 점에서 큰 차이는 없습니다.

Junit5의 룰

@ExperimentalCoroutinesApi
class MainCoroutineExtension:
    BeforEachCallback, AfterEachCallback {

    lateinit var scheduler: TestCoroutineScheduler
        private set
    lateinit var dispatcher: TestDispatcher
        private set

    override fun beforEach(context: ExtensionContext?) {
        scheduler = TestCoroutineScheduler()
        dispatcher = StandardTestDispatcher(scheduler)
        Dispatchers.setMain(dispatcher)
    }

    override fun afterEach(context: ExtensionContext?) {
        Dispatchers.resetMain()
    }
}

• MainCoroutineExtension의 사용법은 Junit4의 MainCoroutineRule과 거의 동일하며, 차이점은 다른 어노테이션을 사용한다는 것입니다.

@JvmField
@RegisterExtension
var mainCoroutineExtension = MainCoroutineExtension()