[KMP] Kotest로 알아본 Stub vs Fake (테스트 더블)

📚<코틀린 코루틴의 정석> 책의 가장 마지막 장인 12장에서는 "코루틴 단위 테스트"에 대해 다룬다.

이때 테스트 더블에 대해 설명해주면서 그 종류 중 하나인 Stub을 들어주었다. 그러나 책을 읽던 당시의 나는 테스트 코드를 처음 접했기에 Stub을 왜 사용하는지 이해가 되지 않았다. 

 

그러다, KMP 프로젝트에서 kotest를 이용해 테스트 코드를 작성할 기회가 있었는데 기존에 사용한 Mockk 라이브러리는 멀티플랫폼에서 사용이 불가하기에 Stub으로 구현해야만 했었다. 이 과정 덕분에 Stub이 무엇인지 이해가 되었고 그 과정을 설명해보려 한다.

 

테스트 더블

우선 테스트 더블에 대해 먼저 알아보자.

테스트 더블이란, 다른 객체와 의존성을 가진 객체를 테스트하기 위해 사용하는 것으로 "객체에 대한 대체물"을 의미한다.

<코틀린 코루틴의 정석> 12장 - 코루틴 단위 테스트

위 그림처럼 "객체"를 테스트 하고 싶은데 이 "객체"가 "다른 객체"에 의존성이 있다면 그 "다른 객체"의 구체적인 구현도 작성해 줘야 한다는 문제가 발생한다.

이 문제를 해결해주는 것이 바로 "테스트 더블"인 것이다.

 

내가 적용했던 "드로이드나이츠"의 코드를 예시로 들어보겠다. 

@Factory
class GetSponsorsUseCase(
    private val sponsorRepository: SponsorRepository,
) {

    suspend operator fun invoke(): List<Sponsor> =
        sponsorRepository
            .getSponsors()
            .sortedBy { it.grade.priority }
}

interface SponsorRepository {

    suspend fun getSponsors(): List<Sponsor>
}

 

필자는 GetSponsorsUseCase에 대한 테스트 코드를 작성하고 싶었다.

그러나 GetSponsorsUseCase는 SponsorRepository에 의존성이 있는 것을 볼 수 있다.

이 때문에 GetSponsorsUseCase를 테스트하기 위해서는 SponsorRepository에 대한 구현체가 있어야 하는 것이다.

 

Stub

그렇다면 이제 Stub으로 문제를 해결해 보자. 

Stub 객체는, 미리 정의된 데이터를 반환하는 모방 객체로 반환값이 없는 동작은 구현하지 않으며, 반환값이 있는 동작만 미리 정의된 데이터를 반환하도록 구현한다.

 

즉, GetSponsorsUseCase를 사용하기 위해 그 모방 객체로 반환값을 작성해주는 작업을 진행하는 것이다.

 

기존에 있던 테스트 코드는 이랬다.

private val getSponsorsUseCase: GetSponsorsUseCase = mockk()

 

Mockk 라이브러리를 통해 GetSponsorsUseCase타입의 가짜 객체를 생성하고 있었다.

 

class StubSponsorRepository(
    private val sponsors: List<Sponsor>
) : SponsorRepository {
    override suspend fun getSponsors(): List<Sponsor> {
        return sponsors
    }
}

 

이를 Stub으로 구현해준다면 위 코드처럼 된다.

반환값이 있는 getSponsors 함수를 구현해주고 있는 것을 볼 수 있다.

그리고 sponsors 데이터를 주입해줌으로써 스텁을 더욱 유연하게 만들어주었다. 그러면 테스트에 필요한 데이터가 들어간 sponsors를 StubSponsorRepository 객체 생성 시 설정할 수 있게 된다.

 

given("후원사 리스트가 존재한다면") {
    beforeTest {
        val stubSponsorRepository = StubSponsorRepository(sponsors = fakeSponsors)
        viewModel = HomeViewModel(GetSponsorsUseCase(stubSponsorRepository))
    }

    then("후원사 데이터를 확인할 수 있다") {
        runTest {
            viewModel.sponsorsUiState.test {
                awaitItem()
                val actual = awaitItem()
                actual.shouldBeInstanceOf<SponsorsUiState.Sponsors>()
            }
        }
    }
}

 

이것이 실제 적용한 테스트 코드인데, 여기서도 볼 수 있듯이 fakeSponsors 리스트를 만들어 테스트 코드를 작성할 때 sponsors를 설정할 수 있는 것이다!

 

Fake

Fake도 테스트 더블의 종류 중 하나이다.

Fake 객체는, 실제 객체와 비슷하게 동작하도록 구현된 모방 객체이다.

 

처음에는 Stub과 Fake의 차이가 무엇인지 헷갈렸는데, Stub은 반환값이 고정되어 있는 반면 Fake는 더 실제 객체처럼 동작할 수 있도록 내부 상태가 잘 구성되어 있다면 보면 된다.

 

예를 들어보면 다음과 같다.

class FakeSponsorRepository : SponsorRepository {
    private val sponsors = mutableListOf<Sponsor>()

    override suspend fun getSponsors(): List<Sponsor> {
        return sponsors.toList() 
    }

    suspend fun addSponsor(sponsor: Sponsor) {
        sponsors.add(sponsor)
    }
    
    suspend fun removeSponsor(sponsor: Sponsor) {
        sponsors.remove(sponsor)
    }
}

 

DB나 네트워크를 통한 저장 대신 인메모리에 저장해 실제 객체처럼 동작하도록 만든 것이다.

 

어떤 테스트 더블을 사용할지는 상황에 따라 선택해주면 될 것 같다.

단순 고정된 값만 주는 경우라면 Stub을, 

데이터 쓰기/읽기 작업처럼 현실적인 로직이 필요하다면 Fake를 사용하면 되겠다.

 

 

📍관련 PR은 옆 링크에서 확인 가능하다 ➡️ https://github.com/Kotlin-Multiplatform-Laboratory/DroidKnightsApp-KMP/pull/19

 

Reference

GitHub - droidknights/DroidKnightsApp: 국내 최대 규모 안드로이드 컨퍼런스 드로이드나이츠 앱

GitHub - seyoungcho2/coroutinesbook: 『코틀린 코루틴의 정석』, 조세영, 에이콘 출판사(2024) 저장소 입니