프로젝트의 규모가 비대해질수록 코드 구조가 중요해지고 이에 따라 의존성 관리를 잘 해주어야 합니다. 의존성이 외부에서 내부로 향할 수 있도록 철저히 해야하고, 모듈 간 인터페이스로 결합이 되므로 필요 시 환경에 따라 인터페이스의 구현을 갈아 끼울 수 있도록 해야합니다.

Tuist로 타겟 의존성 관리하기

Tuist를 사용하여 프로젝트 모듈의 의존성과 외부 의존성을 관리하였습니다.
기존에도 여러 차례 사용 경험이 있었고 쉽게 모듈화를 진행하고 외부 의존성을 관리할 수 있기 때문에 Tuist를 사용하게 되었습니다.

이번 기회에 기존과는 새로운 방법을 시도한 것은 아래와 같이 프로젝트를 구성할 때 앱 타겟과 테스트 타겟 의존성을 따로 받아 타겟에 맞게 프로젝트를 빌드하였습니다.

또한 Project를 구성할 때 App Target의 의존성들과 Test Target 의존성을 매개변수로 받아 각 Target에 맞게 프로젝트를 설정하였습니다.

let project = Project.makeModule(name: "Feature",
                                 product: .staticFramework,
                                 appTargetDependencies: [.SPM.RxCocoa,
                                                         .SPM.RxDataSources,
                                                         .SPM.RxGesture,
                                                         .SPM.RxSwift,
                                                         // ...
                                                         .Workspace.DesignSystem,
                                                         // ...
                                                         ],
                                 testTargetDependencies: [.Workspace.TestUtility]
)

재사용 가능성이 있는 테스트와 관련한 객체 및 함수들을 별도의 모듈로 분리하였고, 테스트 타겟에만 이를 의존하도록 하여 정확하고 편리하게 사용할 수 있었습니다.

---

Swinject로 객체 관리하기

객체들의 의존성은 Swinject를 사용하여 관리하였습니다. Swinject의 의존성 컨테이너를 활용해 보다 간편하게 register, resolve하여 사용할 수 있고, 의존성 등록 시 객체의 생명 주기와 구현 프로토콜 등을 설정할 수 있었기 때문에 다양한 레이어로 나누고 안쪽을 바라보는 구조를 가지고 있는 프로젝트에서 사용하기 적합할 것이라고 판단했습니다.

Feature모듈의 ViewController, ViewModel등의 객체들과
Core, Network등의 모듈의 UseCase, Repository 구현 객체등의 의존성을 모두 Swinject를 통해 관리하였습니다.

🪞 객체 Mocking

Assembly를 사용할 때 아래와 같이 MockableAssembly를 통해 필요 시 Mock 객체 의존성도 함께 등록하였습니다.

import Swinject

public protocol MockableAssembly: Assembly {
    func assembleActual(_ container: Container)
    func assembleMock(_ container: Container)
}

extension MockableAssembly {
    public func assemble(container: Container) {
        self.assembleActual(container)
        self.assembleMock(container)
    }
}

import Swinject

struct MyAssembly: MockableAssembly {
    func assembleActual(_ container: Container) {
    	container.register(MyRepository.self) { _ in return MyRepositoryImpl() }
        container.register(MyUseCase.self) { resolver in
        	let aService = resolver.resolve(AService.self)!
            let bService = resolver.resolve(BService.self)!
            
            return MyUseCaseImpl(aService: aService, bService: bService)
        }
    }
    
    func assembleMock(_ container: Container) {
        container.register(MyRepository.self, name: "Mock") { _ in return MockMyRepositoryImpl() }
        
        container.register(MyUseCase.self, name: "Mock") { resolver in
         	let aService = resolver.resolve(AService.self, name: "Mock)!
            let bService = resolver.resolve(BService.self, name: "Mock)!
            
            return MyUseCaseImpl(aService: aService, bService: bService)
        }
    }
}

그리고 유닛 테스트를 진행할 때나 빌드 스키마에서는 편리하게 Mock 객체를 resolve할 수 있었습니다.

#if DEBUG
	let viewModel = container.resolve(MyViewModel.self, name: "Mock")!
#else
	let viewModel = container.resolve(MyViewModel.self)!
#endif

---

🙄 MockableAssembly은 별로인 듯

MockableAssembly를 통해 실제 구현 객체와 Mock 객체를 환경에 따라 사용했는데, 구현 객체와 Mock 객체가 동시에 필요한 경우는 없었습니다.

따라서 굳이 MockableAssembly 프로토콜을 사용하지 않고, assemble(container: ) 메소드에서 필요 시 직접 스키마 조건 분기를 통해 Mock 객체를 등록하고 이를 바로 사용하는 편이 더 낫다고 생각됩니다.