Test Doubles — 대체 객체의 유형과 활용

Test Doubles란?

Test Doubles는 자동차 산업(스턴트 더블)에서 소프트웨어 개발로 가져온 용어입니다. 스턴트 더블이 위험한 장면에서 배우를 대체하듯이, Test Double은 테스트 시나리오에서 실제 컴포넌트를 대체합니다. 이는 실제 의존성을 사용할 수 없거나, 느리거나, 비결정적이거나, 부작용이 있을 때 필요합니다.

Test Double 개념은 다섯 가지 특정 유형을 포함하며, 각각 고유한 작업을 해결합니다. Meszaros의 유형론은 표준이며 모든 현대 테스트 가이드에서 사용됩니다. 유형 간의 차이는 제어 및 검증의 정도에 있습니다: 단순한 매개변수 채움(Dummy)부터 완전한 호출 시퀀스 검증(Mock)까지입니다.

Test Doubles가 필요한 이유

Test Doubles의 주요 목적은 테스트 대상 모듈의 격리입니다. 모바일 개발에서 실제 의존성에는 API 서버, 데이터베이스, 파일 시스템, 디바이스 센서, 시스템 서비스(LocationManager, Camera, Bluetooth)가 포함됩니다. 이러한 컴포넌트를 직접 사용하면 테스트가 느리고 깨지기 쉬우며 환경에 의존하게 됩니다. Google Testing Blog(2023)에 따르면, 잘 격리된 단위 테스트는 밀리초 단위로 실행되는 반면, 통합 테스트는 초 및 분 단위로 실행됩니다.

Test Doubles의 다섯 가지 유형

Gerard Meszaros의 분류는 다섯 가지 유형의 Test Doubles를 포함하며, 행동과 목적이 다릅니다. 이들 간의 차이를 이해하는 것이 적절한 단위 테스트의 기초입니다.

Dummy

Dummy는 테스트 대상 메서드에 전달되지만 절대 사용되지 않는 객체입니다. Dummy는 메서드 시그니처를 충족시키기 위해서만 필요합니다. Kotlin에서는 주로 null, emptyList() 또는 스텁이 있는 객체입니다. Dummy는 로직을 포함해서는 안 됩니다 — 호출되면 테스트가 실패해야 합니다.

Fake

Fake는 인터페이스의 단순화되었지만 작동하는 구현입니다. Mock 및 Stub과 달리 Fake는 실제 비즈니스 로직을 포함하지만 단순화된 형태입니다. 전형적인 예는 데이터베이스 대신 HashMap에 데이터를 저장하는 InMemoryUserRepository입니다. Fake는 실제 인프라의 오버헤드 없이 상태에 의존하는 로직을 테스트해야 할 때 사용됩니다.

Stub

Stub은 특정 호출에 대해 미리 정의된 값을 반환합니다. Stub은 호출되었는지 확인하지 않습니다 — 단순히 데이터를 제공합니다. Mockito에서 Stub은 when(method).thenReturn(value)를 통해 생성됩니다. Stub은 의존성이 특정 값을 반환해야 하지만 호출 자체는 중요하지 않은 테스트에 이상적입니다.

Spy

Spy는 실제 객체를 감싸는 래퍼로, 나중에 검증하기 위해 모든 호출을 기록합니다. Mock과 달리 Spy는 실제 객체에 호출을 위임하지만 호출이 발생했는지 확인할 수 있습니다. Mockito에서 Spy는 spy(realObject)를 통해 생성됩니다. Spy는 실제 객체를 사용하면서 일부 호출을 검증하려는 부분 목킹에 유용합니다.

Mock

Mock은 미리 정의된 호출 기대치를 가진 객체입니다. Mock은 특정 메서드가 특정 인수와 특정 순서로 호출되었는지 검증합니다. Stub과 달리 Mock은 데이터 반환보다 행동 검증에 초점을 맞춥니다. Mock은 모바일 개발에서 가장 강력하고 가장 자주 사용되는 Test Double 유형입니다.

Mock vs Stub: 주요 차이점

Mock과 Stub의 차이는 숙련된 개발자들 사이에서도 종종 혼란을 야기합니다. 주요 차이는 목적에 있습니다: Stub은 상태 검증(state verification), Mock은 행동 검증(behavior verification)입니다.

Stub은 다음 질문에 답합니다: “코드가 올바른 결과를 반환했는가?”. Mock은 다음 질문에 답합니다: “코드가 올바른 인수로 올바른 메서드를 호출했는가?”. 모바일 개발에서 Stub은 결과가 중요한 경우(예: 리포지토리의 데이터) 사용되며, Mock은 부작용이 중요한 경우(예: 이메일 전송, 데이터베이스 쓰기) 사용됩니다.

// Stub: 상태 검증
every { repository.getUsers() } returns listOf(user)
val result = useCase.getUsers()
assertEquals(1, result.size)

// Mock: 행동 검증
every { analytics.logEvent("purchase") } returns Unit
useCase.purchase(item)
verify { analytics.logEvent("purchase") }

Kotlin의 Test Doubles 예제

MockK를 사용한 Kotlin의 다섯 가지 유형의 Test Doubles 실제 예제 — Android 프로젝트에서 가장 인기 있는 목킹 라이브러리입니다.

Fake: InMemoryUserRepository

class InMemoryUserRepository : UserRepository {
    private val store = mutableMapOf<String, User>()

    override fun save(user: User) {
        store[user.email] = user
    }

    override fun findByEmail(email: String): User? {
        return store[email]
    }
}

Stub + Mock: UseCase 테스트

class RegisterUseCaseTest {
    private val api = mockk<AuthApi>()
    private val repo = spyk(InMemoryUserRepository())
    private val useCase = RegisterUseCase(api, repo)

    fun `register user successfully`() = runTest {
        // Stub: 고정 API 응답 반환
        coEvery { api.register("test@test.com") } returns AuthResult.Success("token123")

        val result = useCase.execute("test@test.com")

        // Verify: 사용자가 저장되었는지 확인
        verify { repo.save(any()) }
        assertTrue(result.isSuccess())
    }
}

Dummy: 사용되지 않는 매개변수로 테스트

data class Logger(val appContext: Context, val format: FormatType)

fun `test logger with dummy context`() {
    // Dummy: Context가 Logger 내부에서 사용되지 않음
    val dummyContext = mockk<Context>()
    val logger = Logger(dummyContext, FormatType.JSON)
    assertEquals(FormatType.JSON, logger.format)
}

모바일 개발에서 각 유형 사용 시기

Test Double 유형의 선택은 무엇을 테스트하는지에 따라 달라집니다: 상태, 행동 또는 통합. Android 및 iOS 모바일 개발에서는 다음과 같은 권장 사항이 확립되었습니다.

ViewModel 및 UseCase의 경우

ViewModel을 테스트할 때는 부작용을 생성하는 의존성(리포지토리, 분석, 네비게이션)에는 Mock을 사용하고, 데이터를 반환하는 의존성(API 클라이언트, ContentProvider)에는 Stub을 사용합니다. 이를 통해 ViewModel이 성공 및 오류 시나리오를 모두 올바르게 처리하는지 검증할 수 있습니다.

Repository 및 데이터 레이어의 경우

Repository 수준에서는 Fake(인메모리 데이터베이스 구현)와 Stub(고정 API 응답)을 선호합니다. Fake를 사용하면 SQLite를 설정하지 않고 캐싱 로직과 오프라인 모드를 테스트할 수 있습니다. Stub은 다양한 HTTP 상태(200, 404, 500, timeout)를 시뮬레이션합니다.

• 비즈니스 로직 단위 테스트 — 모든 외부 의존성에 Mock, 사용되지 않는 매개변수에 Dummy
• 통합 테스트 — Mock 대신 Fake(컴포넌트가 함께 작동하는지 확인)
• UI 테스트 — API 응답에 Stub(MockWebServer 또는 WireMock 통해)
• 캐싱 테스트 — 데이터베이스에 Fake(Room/SQLite 대신 인메모리)
• 비동기 테스트 — 코루틴 지원 Mock(Flow용 MockK + Turbine)

대체 객체 사용 시 흔한 실수

Test Doubles의 잘못된 사용은 리팩토링할 때마다 깨지는 취약한 테스트의 가장 흔한 원인 중 하나입니다.

과도한 모킹: Mock의 과도한 사용

가장 흔한 실수는 모든 것을 모킹하는 것입니다. 테스트의 모든 의존성이 Mock으로 대체되면 테스트는 실제 행동 검증을 중단합니다. Mock은 외부 의존성에만 사용해야 합니다(네트워크, 데이터베이스, 파일 시스템, 시스템 서비스). 내부 애플리케이션 컴포넌트(Value Object, data class, 단순 유틸리티)는 대체해서는 안 됩니다.

사양 부족: 불충분한 명세

두 번째 실수는 기대치를 정의하지 않고 Mock을 만드는 것입니다. every / when 없이 메서드가 호출되면 Mock은 기본값(null, 0, false)을 반환합니다. 이는 Mock이 조용히 null을 반환하고 테스트가 이를 올바른 행동으로 해석하는 위양성 테스트로 이어질 수 있습니다.

과도한 검증: verify의 과도한 사용

세 번째 실수는 모든 Mock의 모든 호출을 검증하는 것입니다. Verify는 비즈니스 로직 관점에서 중요하게 중요한 호출에만 사용해야 합니다. 과도한 검증은 테스트를 취약하게 만듭니다: 프로덕션 코드의 호출 순서 변경이 행동을 변경하지 않고 테스트를 깨뜨립니다.