To-do 앱을 여기까지 끌고 왔으면 이제 기능은 다 있다. ViewModel도 있고, Room도 붙였고, 네트워크도 되고, 화면도 폰/태블릿 다 대응했다.

그런데 생각해보자. 이 앱을 다음 주에 다시 고치면 어떻게 될까? addTodo 로직을 살짝 바꿨는데 다른 데서 뭔가 깨졌는지 어떻게 알아? 매번 앱 켜서 버튼 눌러보고 확인할 거야?

그게 싫어서 테스트를 짠다. 오늘은 두 가지만 본다. ViewModel 로직을 코드로 테스트하는 법, 그리고 화면이 제대로 그려지고 클릭이 되는지 테스트하는 법.

테스트를 왜 두 종류로 나누는가

앱에서 테스트할 게 크게 두 군데다.

• "할일을 추가하면 목록에 1개가 늘어난다" → 이건 순수한 로직. 화면 없이도 확인 가능. → ViewModel 단위 테스트
• "화면에 '추가' 버튼이 보이고, 누르면 입력한 텍스트가 목록에 나타난다" → 이건 실제로 그려진 화면이 필요함. → Compose UI 테스트

이 둘은 돌아가는 방식부터 다르다. 단위 테스트는 그냥 JVM에서 돈다. UI 테스트는 (가상이든 실제든) 안드로이드 기기가 있어야 돈다. 그래서 폴더도 다르다.

• app/src/test/ → ViewModel 테스트, JVM에서 빠르게 돔
• app/src/androidTest/ → Compose UI 테스트, 기기/에뮬레이터 필요

1. ViewModel 테스트부터: 처음 돌리면 바로 터진다

TodoViewModel에 addTodo("빨래하기")를 호출하고 uiState.value.todoList에 1개가 들어있는지 확인하는 테스트를 짜본다고 하자. 제일 단순하게 짜면 이렇게 될 거다.

@Test
fun `할일을 추가하면 목록이 늘어난다`() {
    val repository = FakeTodoRepository()
    val viewModel = TodoViewModel(repository)

    viewModel.addTodo("빨래하기")

    assertEquals(1, viewModel.uiState.value.todoList.size)
}

돌려보면 바로 이런 에러가 뜬다.

IllegalStateException: Module with the Main dispatcher had failed to initialize.

왜 이게 터질까. TodoViewModel 안에서 uiState는 stateIn(viewModelScope, ...)로 만들었다. viewModelScope는 내부적으로 Dispatchers.Main을 쓰는데, 테스트는 안드로이드 기기 위가 아니라 그냥 JVM에서 돈다. JVM에는 안드로이드의 "메인 스레드"라는 게 없으니까, Dispatchers.Main을 쓰려는 순간 "그런 거 없다"면서 터지는 거다.

고치기: 테스트용 Main 디스패처를 끼워넣기

이럴 때 쓰라고 코루틴 쪽에서 kotlinx-coroutines-test 라이브러리를 제공한다. Dispatchers.setMain()으로 테스트 전용 디스패처를 Main 자리에 끼워넣으면 된다.

// build.gradle.kts (app) - testImplementation
testImplementation("org.jetbrains.kotlinx:kotlinx-coroutines-test:1.11.0")
testImplementation("junit:junit:4.13.2")

@OptIn(ExperimentalCoroutinesApi::class)
class TodoViewModelTest {

    private val testDispatcher = StandardTestDispatcher()

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

    @After
    fun tearDown() {
        Dispatchers.resetMain()
    }

    @Test
    fun `할일을 추가하면 목록이 늘어난다`() = runTest {
        val repository = FakeTodoRepository()
        val viewModel = TodoViewModel(repository)

        viewModel.addTodo("빨래하기")
        testDispatcher.scheduler.advanceUntilIdle()

        assertEquals(1, viewModel.uiState.value.todoList.size)
    }
}

하나씩 보자.

• Dispatchers.setMain(testDispatcher): "Main 디스패처 달라고 하면 이걸 줘"라고 테스트 시작 전에 등록해두는 거다. @Before에 두면 테스트 하나하나 돌 때마다 매번 다시 설정됨.
• runTest { ... }: 코루틴을 쓰는 테스트 본문을 감싸는 함수. 안에서 쓰는 가상 시간을 제어할 수 있게 해준다.
• testDispatcher.scheduler.advanceUntilIdle(): addTodo가 내부적으로 코루틴을 실행해서 DB에 저장하고 Flow가 갱신되기까지는 시간이 걸린다. 이 한 줄이 "대기 중인 코루틴 작업을 다 끝낼 때까지 가상 시간을 돌려줘"라는 뜻이다. 이게 없으면 uiState가 아직 업데이트되기 전에 assertEquals가 먼저 실행돼서 테스트가 실패할 수 있다.

진짜 Repository 대신 Fake를 쓰는 이유

위 코드에서 FakeTodoRepository()를 썼다. 실제 TodoRepository는 Room DB랑 Retrofit API를 들고 있는데, 단위 테스트에서 진짜 DB를 붙이면 느려지고, 네트워크를 붙이면 테스트가 인터넷 상태에 따라 실패하기도 한다. 그래서 테스트에서는 메모리에 리스트 하나만 들고 흉내만 내는 가짜 Repository를 만들어 쓴다.

class FakeTodoRepository : TodoRepository {
    private val todos = MutableStateFlow<List<Todo>>(emptyList())
    override val todoList: Flow<List<Todo>> = todos

    override suspend fun addTodo(title: String) {
        todos.value = todos.value + Todo(id = todos.value.size + 1, title = title)
    }

    override suspend fun toggleDone(todo: Todo) {
        todos.value = todos.value.map {
            if (it.id == todo.id) it.copy(isDone = !it.isDone) else it
        }
    }

    override suspend fun deleteTodo(todo: Todo) {
        todos.value = todos.value.filter { it.id != todo.id }
    }
}

이게 되려면 TodoRepository가 클래스가 아니라 인터페이스여야 한다. 지금까지는 클래스로 썼다면, 이 시점에서 인터페이스로 뽑아내고 실제 구현(TodoRepositoryImpl)과 가짜 구현(FakeTodoRepository)으로 나누는 작업이 한 번 필요하다. 테스트하기 좋은 구조로 바뀌는 과정이라고 보면 된다.

2. Compose UI 테스트: 화면이 그려지는지 직접 확인

이번엔 TodoListScreen에 "추가" 버튼을 누르면 입력한 텍스트가 목록에 나타나는지 확인해보자. 이건 app/src/androidTest/에 둔다.

// build.gradle.kts (app) - androidTestImplementation
androidTestImplementation("androidx.compose.ui:ui-test-junit4:1.12.1")
debugImplementation("androidx.compose.ui:ui-test-manifest:1.12.1")

class TodoListScreenTest {

    @get:Rule
    val composeTestRule = createComposeRule()

    @Test
    fun 할일을_추가하면_목록에_나타난다() {
        var todoList = listOf<Todo>()

        composeTestRule.setContent {
            var list by remember { mutableStateOf(listOf<Todo>()) }
            TodoListScreen(
                todoList = list,
                onAdd = { title ->
                    list = list + Todo(id = list.size + 1, title = title)
                },
                onToggleDone = {},
                onDelete = {},
                onTodoClick = {}
            )
        }

        composeTestRule.onNodeWithText("할일을 입력하세요").performTextInput("우유 사기")
        composeTestRule.onNodeWithText("추가").performClick()

        composeTestRule.onNodeWithText("우유 사기").assertExists()
    }
}

여기서 처음 보는 게 composeTestRule이다.

• createComposeRule(): 테스트 안에서 컴포즈 화면을 그릴 수 있게 해주는 규칙. @get:Rule을 붙이면 테스트마다 자동으로 준비되고 정리된다.
• composeTestRule.setContent { ... }: MainActivity의 setContent랑 똑같은 역할인데, 테스트용 가짜 화면에 그리는 거다.
• onNodeWithText("추가"): 화면에서 "추가"라는 텍스트를 가진 노드를 찾는다. 버튼이든 텍스트든 상관없이, 화면에 보이는 글자로 찾는다.
• .performClick() / .performTextInput(...): 찾은 노드를 클릭하거나 텍스트를 입력하는 "사람이 하는 행동"을 코드로 흉내낸다.
• .assertExists(): 그 노드가 화면에 실제로 존재하는지 확인한다. 없으면 테스트 실패.

이 테스트가 좋은 점은, ViewModel이나 Repository 없이 TodoListScreen만 뚝 떼서 테스트한다는 거다. 12번 글에서 "상태 호이스팅"으로 TodoListScreen을 stateless로 만들어둔 게 여기서 그대로 보상받는다. 파라미터로 값을 받고 콜백으로 이벤트를 내보내는 구조라서, 가짜 상태(remember { mutableStateOf(...) })만 하나 만들어주면 ViewModel 없이도 화면만 독립적으로 테스트할 수 있다.

삽질 사례: onNodeWithText가 자꾸 못 찾는다고 한다

AssertionError: Failed to find a node for text: 우유 사기

흔한 원인 두 가지.

1. 타이밍: performClick() 직후 바로 assertExists()를 부르면, 아직 리컴포지션이 끝나기 전일 수 있다. 보통은 composeTestRule이 자동으로 기다려주지만(idling resource), 코루틴을 직접 돌리는 코드가 섞여 있으면 간혹 안 맞을 때가 있다. 그럴 땐 composeTestRule.waitForIdle()을 중간에 넣어본다.
2. 텍스트가 잘려서 안 보임: 긴 텍스트는 화면에 ...로 잘려서 실제 노드 텍스트가 다를 수 있다. onNodeWithText("우유", substring = true)처럼 부분 일치로 찾으면 해결된다.

정리

• ViewModel 테스트는 app/src/test/에, Compose UI 테스트는 app/src/androidTest/에 둔다. 전자는 JVM에서, 후자는 기기/에뮬레이터에서 돈다.
• ViewModel이 viewModelScope(= Dispatchers.Main)를 쓰면 테스트에서 바로 터지니까, kotlinx-coroutines-test의 Dispatchers.setMain() + runTest + advanceUntilIdle()로 가짜 Main 디스패처를 끼워넣어야 한다.
• 진짜 DB/네트워크를 든 Repository 대신, 인터페이스를 뽑아 메모리로 흉내 내는 Fake 구현을 테스트에서 쓴다.
• Compose UI 테스트는 createComposeRule() + onNodeWithText + performClick/performTextInput으로 화면을 사람처럼 조작하고 확인한다.
• stateless 컴포저블로 짜둔 화면은 ViewModel 없이도 UI 테스트가 쉽다. 8번 글의 상태 호이스팅이 여기서 다시 쓰인다.

다음 글에서는 이 앱을 실제로 Play 스토어에 올리는 과정을 본다. 서명 키는 왜 두 종류가 있는지, AAB는 뭔지, Play Console에 처음 등록할 때 뭘 준비해야 하는지 정리한다.