문제 상황 : API로 데이터를 받아 사용하는 ViewModel을 테스트하기 위해선 Network 객체도 테스터블하게 만들어야했습니다.

해결 방법

• URLProtocol을 상속한 MockURLProtocol을 구현했습니다.
• MockURLProtocol에 서버와 통신을 통해 받은 data와 response대신 mockResponse, data 를 전달하도록 startLoading() 오버라이딩했습니다.
• 따라서 실제 통신을 하지 않고도 작동하는 mock APIService구현할 수 있었습니다.

➡️ APIService의 코드 수정 없이, MockURLProtocol로 설정한 URLSessionConfiguration을 주입하여 네트워크와 무관하게 바인딩, 뷰 모델 로직 테스트 가능해졌습니다.

test: MockURLProtocol 구현 및 테스트 코드 적용

문제 상황

1. 실제 사용자 이벤트 대신 테스트 이벤트를 조작해야합니다.
2. Input에 들어갈 ControlProperty 타입을 만들어야합니다.
3. ViewModel은 Usecase에 의존하기 때문에 Usecase의 동작에 영향을 받습니다.

해결 방법

• TestScheduler 로 ColdObservable 을 생성하여 사용자 이벤트를 대신할 이벤트를 예약한후, ControlProperty의 값을 나타낼 BehaviorSubject에 바인드했습니다.
• ControlProperty는 최초의 UIVaule를 이벤트로 내보냅니다. 따라서 BehaviorSubject로 최초 값을 정의하고 실제와 동일한 테스트 환경을 만들었습니다.
• input에서 output으로 변환되는 과정에서 Usecase를 사용해야하만 하는 경우가 있었습니다. (다수의 Field에서 input을 받아 Usecase에서 검증하는 경우) Usecase만을 먼저 독립적으로 테스트하고(MockRepository 사용) Usecase 의 신뢰성을 검증 한 후 ViewModel을 테스트했습니다.
• ViewModel 과 Usecase 간 강한 결합이 있다는 문제를 인지했고 뷰 모델을 더 단순화해야겠다고 느꼈습니다.
• 테스트 코드는 버그의 조기발견, 안정성뿐만 아니라 더 나은 코드를 작성하는데 도움이 된다는 것을 느낄 수 있던 경험이었습니다.

문제 상황 : 뷰 컨트롤러에서 각 에러에 따른 알림을 사용자에게 차별적으로 보여주려면 에러를 구독해합니다. 하지만 에러가 한 번 방출되면 스트림은 종료되고, 다시 이벤트를 받지 못합니다.

시도

• retry를 쓰면 에러가 방출되어도 그 즉시 dispose되고 다시 구독되기 때문에 스트림을 살릴 수 있지만, 에러가 옵저버에게 전달되지 않기 때문에 뷰에서 어떤 에러가 방출됐는지 알 수 없습니다.
• catch(onErrorJustReturn:), asDriver(onErrorJustReturn:) 를 쓰면 에러대신 다른 값을 넥스트로 보내고 complete되기 때문에 더 이상 사용자 이벤트를 받을 수 없습니다.
• Result타입으로 값과 에러를 wrapping해서 next로 방출하면 뷰에서 핸들링이 가능합니다. 하지만 뷰컨이 분기를 하는 것과 같은 로직을 갖게되어 역할 분리 측면에선 좋은 방법은 아니라 판단했습니다.

해결 방법

• 뷰에 AlertController의 뷰모델을 전달하는 스트림을 Subject타입으로 구현했습니다.
• 스트림에서 error방출시 do에서 Subject에게 AlertViewModel을 next로 보냈습니다.

protocol AlertViewModel {
    
    var title: String? { get }
    var message: String? { get }
    var actionTitle: String? { get }
}

문제 상황 : 이미지는 용량이 크기 때문에 스크롤 할 때마다 셀에 느리게 바인딩되는 상황이었습니다.

해결 방법

• UIImage+Extension에 NScache를 사용해 해당 이미지 URL을 key로 데이터를 캐싱했습니다.

➡️ 사용성과 통신 비용을 개선했습니다.

Escaping Closure는 참조타입으로 강한 순환 참조로 인한 메모리 누수를 유발할 수 있습니다.

• 객체의 reference count를 증가 시켜야할 상황인지 판단해 참조를 해야한다는 것, [weak self] unowned로 강한 순환참조를 해결할 수 있다는 점을 학습했습니다.

• RxSwift의 operator들은 escaping closure로 정의 되어있습니다. 따라서 뷰컨트롤러를 [weak self]로 참조해야만 disposeBag이 작동될 때 모든 스트림이 종료되고, 뷰 컨트롤러도 해제될 수 있습니다.

• 직접 HTTP header, body, httpMethod, boundary를 구현해보며 HTTP 프로토콜의 구조에 대해 학습할 수 있었습니다.
• APIRequest를 프로토콜로 정의하여, 개별 Request 생성시 프로토콜을 구현했습니다.
• POP를 직접 적용해봄으로싸 확장성과 유연성을 이해할 수 있었습니다.

protocol APIRequest {
   // Request에 대한 Response Parsing Type을 연관 타입으로 정의
    associatedtype Response: ResponseDataType
    
    var url: URL? { get }
    var httpMethod: HTTPMethod { get }
    var header: [String: String] { get }
    var body: Data? { get }
    
}

extension APIRequest {
    
    // 프로토콜 기본 구현을 활용해 편리하게 URLRequest를 생성하는 API 제공
    func urlRequest() -> URLRequest? {
        guard let url = url else {
            return nil
        }
        
        var urlRequest = URLRequest(url: url)
        urlRequest.httpMethod = httpMethod.rawValue
        urlRequest.allHTTPHeaderFields = header
        urlRequest.httpBody = body
        return urlRequest
    }
    
}