Coordinator 리팩토링 검증을 위한 테스트 코드 작성

[yungu0010]

Coordinator 리팩토링을 검증하기 위한 테스트 코드 도입에 대해 논의하기 위해 Discussion을 열었습니다!🙇‍♂️

이전 Discussion #514에서 논의했던 Coordinator 리팩토링이 어느 정도 진행되었는데요.
레거시 코드를 걷어내기 전에, 현재 패턴이 의도대로 동작하는지 검증할 안전망이 필요하다고 생각해서 테스트 코드 도입을 제안드려봅니다! 👀

---

📍 현재까지의 리팩토링 과정

Coordinator는 두 단계에 걸친 리팩토링을 진행해왔습니다.

1단계: Router 제거 (Discussion #514)

Router 추상화의 이점이 크게 활용되지 않고 네비게이션 불일치 문제, rootViewController 전환 등의 문제가 생긴다는 논의를 바탕으로, UINavigationController를 직접 주입하는 방식으로 변경했습니다.

2단계: Coordinator 인스턴스 해제 방식 변경

기존에는 모든 Coordinator가 finishFlow() 호출과 addDependency() 등록을 수동으로 관리해야 했는데요.
하나라도 누락되면 메모리 누수가 발생했고, 실제로 이전 PR에서 누락된 경우가 확인되기도 했습니다.

이에 강한참조를 활용하여 Coordinator의 생명주기를 관리하는 방식으로 리팩토링을 진행했습니다.

[현재 구조]

graph LR
    NC["NavigationController"]
    C["Coordinator"]
    VM["ViewModel"]
    VC["ViewController"]
 
    NC -. "weak" .-> C
    VC -- "strong" --> VM
    VM -- "strong" --> C
 
    style NC fill:#f0f4f8,stroke:#94a3b8,color:#334155
    style C fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f
    style VM fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f
    style VC fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f

Loading

• ViewModel이 Coordinator를 강하게 소유하고, NavigationController는 Coordinator를 약하게 참조
• 화면이 dismiss되어 VC가 해제되면 VM이 해제되고, 연쇄적으로 Coordinator도 자동으로 해제
• 단, 해당 플로우가 종료된 이후 동작이 필요한 경우를 위해 CoordinatorFinishOutput 프로토콜을 통해 finished 클로저를 외부에 노출함으로써, 부모 Coordinator는 자식 종료 시점을 알 수 있으면서도 자식 Coordinator를 강하게 참조하지 않는 구조로 설계했습니다.

(아직 TabBar나 MyPage 등에 addDependency나 finishFlow 등이 잔존하고 있어 순차적으로 제거가 필요합니다.)

---

💡 테스트 코드의 필요성

레거시 코드를 본격적으로 걷어내기 전에 테스트 코드가 먼저 필요하다고 생각한 이유는 크게 세 가지입니다.

1. 현재 패턴이 의도대로 동작하는지 보장

리팩토링 이후에도 기존과 같이 기능이 잘 동작하는지 보장이 되어야 했는데요, ViewModel이 UseCase 이벤트를 받아 콜백 클로저를 올바른 타이밍에 호출하는 것이 핵심이라고 생각했습니다. Coordinator는 그 콜백을 클로저와 연결할 뿐이기 때문에, ViewModel의 transform 로직이 제대로 동작하는지 확인하는 것이 첫 번째 목적이었어요.

sequenceDiagram
    participant C as Coordinator
    participant VM as ViewModel
    participant UC as UseCase
 
    C ->> VM: 콜백 클로저 와이어링<br/>(onNoticeSkipped, onNoticeExist 등)
    C ->> VM: transform() 호출
    VM ->> UC: getAppNotice()
    UC -->> VM: needUpdate 이벤트 발행<br/>(.none / .forcedUpdate / .optionalUpdate / .networkError)
    VM ->> C: 매핑된 콜백 클로저 호출

Loading

2. 레거시 제거 시 회귀 방지

테스트가 통과하는 상태를 유지하면서 레거시 코드를 제거하면, 기존 동작이 깨지는 것을 방지할 수 있고, 문제가 생기는 경우 원인을 빠르게 찾아낼 수 있습니다.

3. 기수제 환경에서의 지속 가능성

메이커스 특성상 6개월마다 인원이 바뀔 수 있는 기수제이다보니, 구두로 전달되던 컨텍스트가 사라지는 일이 종종 있었어요. 테스트 케이스 자체에 명세처럼 담겨 있으면, 히스토리를 모르는 분도 코드 의도를 빠르게 파악할 수 있을 거라 생각했습니다.

---

SplashFeature 테스트 코드 작성 과정

SplashFeature가 다른 기능 모듈과의 의존성도 없고, 구조가 간단하기 때문에 샘플로 정했습니다.

SUT로 ViewModel을 선택한 이유

테스트 대상(SUT)으로 ViewModel을 선택한 이유는 두 가지입니다.

1. 테스트 가능한 경계

• ViewModel은 UseCase 인터페이스에만 의존하므로, Mock으로 완전히 격리할 수 있습니다.
• 반면 Coordinator는 UINavigationController와 직접 상호작용하기 때문에 Unit Test에 적합하지 않습니다.

2. 리팩토링의 핵심 로직 위치

• UseCase 이벤트 → 콜백 클로저 호출의 매핑은 ViewModel의 bindOutput 내부에 있습니다. 적절한 콜백이 잘 실행되는지 검증해야하므로 ViewModel을 검증하는 것이 정확하다고 판단했습니다.

graph TB
    subgraph legacy["기존 패턴 (수동 해제)"]
        direction TB
        L1["Coordinator 생성"] --> L2["addDependency()로 등록"]
        L2 --> L3["화면 전환 로직 실행"]
        L3 --> L4["finishFlow() 수동 호출"]
        L4 --> L5["부모가 의존성 제거"]
        L4 -. "누락 시" .-> L6["⚠️ 메모리 누수"]
    end
 
    subgraph current["신규 패턴 (자동 해제)"]
        direction TB
        N1["Coordinator 생성"] --> N2["VC → VM → Coordinator 체인 형성"]
        N2 --> N3["콜백 클로저 와이어링"]
        N3 --> N4["화면 dismiss → VC 해제"]
        N4 --> N5["VM 해제 → Coordinator 자동 해제"]
    end
 
    style legacy fill:#fef2f2,stroke:#ef4444
    style current fill:#f0fdf4,stroke:#22c55e
    style L6 fill:#fee2e2,stroke:#ef4444,color:#991b1b

Loading

TestDouble 구성

MockSplashUseCase

final class MockSplashUseCase: SplashUseCase {
    var getAppNoticeCalled = false
    var needUpdate = PassthroughSubject<UpdateType, Never>()

    func getAppNotice() {
        getAppNoticeCalled = true
    }
}
- needUpdate를 PassthroughSubject로 노출해서, 테스트에서 원하는 시점에 이벤트를 주입할 수 있게 했습니다.

**`MockSplashCoordinator`**
```swift
final class MockSplashCoordinator: Coordinator {
    func start() { }
    func start(with option: DeepLinkOption?) { }
    func start(by style: CoordinatorStartingOption) { }
}

• ViewModel 생성자가 Coordinator 타입을 요구하므로 최소 구현체로 작성했습니다.
• SplashViewModel 내부에서 AnyCoordinatorObject로 래핑되어 생명주기 관리에 활용됩니다.

XCTest 대신 Swift Testing을 선택한 이유

이번 테스트에서 Swift Testing(import Testing)을 선택했는데요, 이유는 다음과 같습니다.

• 가독성: @Test("설명") 어노테이션으로 테스트 의도를 바로 드러낼 수 있고, #expect 매크로가 XCTAssert 계열보다 실패 시 diff가 명확합니다.
• 구조화: @Suite로 테스트를 논리적으로 그룹화할 수 있어, 케이스가 늘어나도 관리하기 편합니다.
• Swift 네이티브: Xcode 16+, Swift 5.9+에서 공식 지원되고, Combine의 async/await 통합이 자연스럽습니다.

테스트 코드의 비동기 처리 고민

작성하면서 가장 고민됐던 부분은 비동기 처리였습니다.

ViewModel의 bindOutput이 receive(on: DispatchQueue.main)으로 메인 스레드에서 콜백을 실행하는데, 테스트에서 이걸 동기적으로 기다리기 위해 아래 헬퍼를 작성했습니다.

private func flushMainQueue() async {
    await withCheckedContinuation { continuation in
        DispatchQueue.main.async { continuation.resume() }
    }
}

메인 큐에 빈 태스크를 하나 올려서, 그 앞에 적재된 ViewModel 콜백이 먼저 실행되는 걸 보장하는 방식입니다. 더 나은 방법이 있으면 의견 남겨주세요!

---

현재까지 작성된 테스트 케이스

긍정 케이스(호출됨)와 부정 케이스(호출되지 않음)를 함께 검증하여, 의도한 콜백만 실행되는지 확인했습니다.

케이스	검증 내용
transformCallsGetAppNotice	transform 호출 시 useCase.getAppNotice() 실행 여부
noneEmitsOnNoticeSkipped	.none → onNoticeSkipped 호출
forceUpdateEmitsOnNoticeExist	.forcedUpdate → onNoticeExist + 모델 전달
optionalUpdateEmitsOnOptionalNoticeExist	.optionalUpdate → onOptionalNoticeExist + 모델 전달
networkErrorEmitsOnNetworkError	.networkError → onNetworkError + retry 클로저 전달 및 재호출 검증
forcedUpdateDoesNotEmitOnNoticeSkipped	.forcedUpdate 시 onNoticeSkipped 미호출 확인
optionalUpdateDoesNotEmitOnNoticeSkipped	.optionalUpdate 시 onNoticeSkipped 미호출 확인
networkErrorDoesNotEmitOnNoticeSkipped	.networkError 시 onNoticeSkipped 미호출 확인

---

🚀 향후 계획

레거시 Coordinator 코드를 플로우별로 순차 제거할 예정입니다.

1. SplashFeature 테스트 머지
2. 다른 Feature로 테스트 확장
3. 레거시 순차 제거 → LegacyRouter, finishFlow, addDependency 등을 테스트가 보장하는 범위 내에서 제거
4. 리팩토링 미반영 모듈 마이그레이션(TabBar, MyPage 등 레거시 패턴 전환)

테스트 코드 작성이나 리팩토링 방향에 대해 의견 있으면 편하게 남겨주세요! 👀

@juri123123 @kwonseokki

[juri123123]

친절한 discussion 덕분에 이해가 잘 되네요 !! 🚀
현재 리팩토링의 핵심 요소인 coordinator 인스턴스의 생명주기에 관한 테스트 케이스도 추가하면 좋을 것 같습니다 ! 

예시

@Test("ViewModel 해제 시 Coordinator 해제")
func coordinatorDeallocatesWithViewModel() {
    weak var weakCoordinator: MockSplashCoordinator?

    autoreleasepool {
        let coordinator = MockSplashCoordinator()
        weakCoordinator = coordinator

        let vm = SplashViewModel(
            useCase: MockSplashUseCase(),
            coordinator: coordinator
        )
    }

    // 스코프 종료 → vm 해제 → coordinator 해제
    #expect(weakCoordinator == nil)
}

🔍 weak로 선언한 이유

테스트에서 weak로 선언한 것은 구조를 바꾸기 위함이 아니라 관찰하기 위함입니다.

만약 아래와 같이 작성한다면,

var coordinator = MockSplashCoordinator()

테스트 코드가 coordinator를 계속 소유하게 되어
ViewModel이 해제되더라도 coordinator가 해제되지 않습니다.

🔍 autoreleasepool을 사용한 이유

해제 시점을 명확하게 보장하기 위해 사용했습니다.
autoreleasepool을 사용해 블록 종료 시점에 메모리 정리를 강제했습니다.

실제로 테스트를 돌려보지는 못해서 오류나 다른 제안이 있다면 편하게 말씀해주세요 !!

[kwonseokki12]

친절한 설명 감사합니다! Coordinator 부분이 헷갈리는게 많았는데, 이전 히스토리까지 한번에 정리를 해주셔서 많은 도움이 되었어요.

테스트코드의 필요성과 말씀하신 점진적인 테스트 -> 레거시 제거 방식은 너무나 좋다고 생각합니다.

다만 조금 염려되는 부분은 대부분이 반응형프로그래밍 방식으로 이루어져 있어서 테스트코드 또한 그에맞게 작성이 될텐데,
추후 저희가 Swift-Concurreny 방식으로 바꾼다면 모든 Feature에 대한 테스트코드 또한 마이그레이션이 필요할 것으로 예상되어서요.

flushMainQueue 와 같은 Helper 메서드를 사용해야만 정상적인 테스트가 가능한점 그리고 Swift-Concurrency로 리팩토링 했을때 테스트코드를 다시 작성하는 리소스를 생각하면 선수작업으로 Swift-Concurrency로 미리 마이그레이션하는 방법은 어떻게 생각하시나요!?

말이 조금 복잡해졌는데 정리하자면

• 테스트방식 구조의 변화와 이미 작성된 모든 Feature에 대한 테스트코드 재작성 비용 우려
• 비동기 테스트 시 flushMainQueue 같은 Helper 메서드 사용
• Swift-Testing과 Swift-Concurrency 의 호환성

레거시제거 작업이 우선이라고 생각합니다. 다만 해당 작업에대한 리소스가 꽤나 클것으로 예상되어
해당 부분에 대해서 어떻게 생각하시는지 궁금해서 코멘트 달아봅니다.

[yungu0010]

@juri123123 @kwonseokki 두 분 다 좋은 답변 감사해요!

현재 패턴의 핵심이 VC → VM → Coordinator 강함 참조를 통한 코디네이터 해제인데, 막상 그걸 직접 검증하는 테스트가 없었네요🤔
weak + autoreleasepool으로 해제 시점을 검증하는 방식도 좋은 것 같습니다! 다음 PR에 해당 케이스도 함께 추가해볼게요.

---

두번째로 석기님이 말씀해주신 우려에 충분히 공감합니다! 다만 저는 순서를 반대로 진행하는게 좋을 것 같아요.

테스트 없이 Swift Concurrency 마이그레이션을 먼저 진행하면, 그 과정에서 기존 동작이 깨져도 확인할 방법이 없어서 오히려 더 큰 리스크가 생길 것 같습니다. 또한 flushMainQueue 같은 헬퍼도 Swift Concurrency로 전환 시 await으로 대체되기 때문에 테스트 코드 재작성 비용이 생각보다 크지 않을 것 같아요..!
가장 큰 이유는 Swift Concurrency 전환 후 테스트 코드 작성, 레거시 제거로 작업을 진행할 경우 38기 이내에 작업을 끝낼 수 없을 것 같습니다😭

그래서 아래 순서로 가는 게 현실적이라고 생각해요.

1. Combine 기반 테스트 작성
2. 레거시 순차 제거
3. Swift Concurrency 마이그레이션 시 테스트도 함께 업데이트

두 분 의견도 남겨주시면 확인 후 작업 진행하겠습니다! 👀