[iOS] 메이트러너: 우당탕탕 RxTest를 이용한 단위테스트

메이트 러너 앱 개발 과정을 공유하는 포스트입니다!

GitHub - boostcampwm-2021/iOS06-MateRunner: 함께 달리는 즐거움, Mate Runner 🏃🏻‍♂️🏃🏻‍♀️

여기서 저희 프로젝트를 더 자세히 볼 수 있어요!

 

그럼 시작하겠습니다!

 

MVVM에 클린 아키텍처까지 해놓고 테스트를 안 한다고?

저희 팀은 MVVM과 클린 아키텍처를 프로젝트에 적용했는데요, 이런 구조로 나누었을 때 얻는 큰 이점 중 하나가 테스트가 용이한 구조입니다. 프로젝트 마무리까지 딱 한 주, 저희 팀은 남은 한 주의 목표를 우리가 나눈 뷰 모델과 유즈 케이스를 완벽하게 단위 테스트해보는 것으로 잡았습니다.

 

그렇게 이슈를 등록했고

이렇게 44개의 이슈가 등록됩니다...ㅋㅋㅋㅋ 언제 다 해..?

 

테스트 설계

저희는 뷰 모델을 Input/Output으로 모델링하여 설계했고, 유즈 케이스에는 뷰 모델에서 호출할 비즈니스 로직을 정의해두었기 때문에 테스트 대상을 정의하는 것은 어렵지 않았습니다.

뷰 모델은 이렇게 Input에 대해 Ouput이 원하는 대로 잘 나오는지를 테스트하는 것을 목표로 삼았고,

유즈 케이스는 프로토콜에 정의한 함수들이 의도했던 대로 결과를 만드는지 테스트하는 것을 목표로 삼았습니다.

 

근데 우린 다 Rx잖아..

그런데 저희 팀은 거의 모든 비즈니스 로직의 결과와 뷰 모델 Ouput의 프로퍼티를 스트림을 통해 흘러가도록 했다는 것 때문에 테스트를 시작할 때 큰 혼란이 있었습니다. Rx 자체가 처음 해보는 경험이었기 때문에 단위 테스트를 하는 것도 조금은 막막했죠.

 

그래서 열심히 서칭을 해본 결과 RxTest 라이브러리를 사용해서 가상의 시간에 input 데이터를 방출시키고 이 데이터에 대해 발생하는 결과 값들을 테스트하기로 결정했습니다.

 

RxTest로 테스트하기

RxTest로 테스트를 진행할 때는 TestScheduler 객체를 적극적으로 활용했습니다. 아래는 달리기 운동 중 화면의 뷰 모델에 대한 테스트입니다. 이 테스트를 기준으로 어떻게 RxTest로 단위 테스트를 진행했는지 이야기해보겠습니다!

먼저 이렇게 매 테스트가 시작될 때 TestScheduler의 시작시간을 가상 시간 "0"으로 먼저 설정합니다.

 

그리고 스케줄러를 통해 뷰 모델에서 방출되는 값들을 받을 Observer를 하나 생성합니다. 여기서는 정수로 된 초단위 시간이 mm:ss 형태로 포맷팅이 잘 되는지 확인하는 테스트이기 때문에 옵저버가 받을 데이터의 타입을 String으로 지정해주었습니다.

 

옵저버가 있다면 옵저버블도 있어야겠죠? 단위 시간 10에 Void를 방출하는 옵저버블도 하나 생성했습니다. 이 Void는 이 뷰 모델에 연결된 화면이 처음 로드되었을 때에 대한 ViewDidLoad 이벤트의 발생을 의미합니다. 

 

따라서 뷰 모델의 Input을 정의할 때 방금 생성한 옵저버블을 viewDidLoadEvent에 넣어주고, 나머지 프로퍼티들은 모두 just로 딱 한 번만 데이터를 방출시켜줍니다.

 

이제 뷰 모델의 input을 ouput으로 변환하는 transform 메서드를 실행하고 ouput에 있는 timeSpent 프로퍼티를 구독해 테스트용 옵저버에 바인딩을 해줍니다. 

 

갑자기 take(2)가 왜 나왔나 싶죠? 잠시 후에 설명하겠습니다!

 

마지막으로 스케줄러를 실행시키면 아까 만들었던 옵저버블의 가상시간 10에 Void를 방출하는 동작이 시작됩니다. 

데이터가 방출되었으니 뷰 모델이 작업을 수행했겠죠! 그리고 뷰모델이 방출한 데이터가 String 타입을 값으로 받는 옵저버에 들어갔을 것입니다.

 

Scheduler를 통해 생성한 옵저버는 최근 값뿐만 아니라 자신이 스트림에서 받은 모든 값과 단위 시간에 대한 기록을 events 배열에 가지고 있기 때문에, 이 배열이 내가 원하는 것과 같은지 확인하면 테스트를 수행할 수 있습니다.

 

위에서는 10초가 지났을 때 문자열이 잘 만들어지는지 테스트했고, 구독을 시작했을 때 방출된 초기값인 "00:00"과 테스트하고 싶었던 기대 값인 "00:10"이 잘 도착하는 것을 확인할 수 있었습니다.

 

HH:MM:SS 면 어떡해..?

위에서 진행했던 단위 테스트는 타이머에서 방출되는 경과시간이 문자열 포맷으로 잘 변경되는지 확인하는 테스트였습니다. 뷰 모델의 input을 ouput으로 변환하는 메서드 자체가 유즈 케이스에 의존적이기 때문에 뷰 모델에 직접 시간 값을 주는 건 불가능하죠.

 

그럼 결국 기존 유즈 케이스를 사용해야 하는데, 두 가지 문제점이 있습니다. 

 

1. 유즈 케이스가 잘못되면 뷰 모델에 대한 단위 테스트가 오염된다.

2. 몇 시간 동안 켜놓고 기다려야 한다.

 

유즈 케이스도 결국 우리가 만든 코드인데 정상적으로 값이 잘 방출된다고 확신할 수 있을까요? 그리고 1시간이 넘어가는 데이터를 테스트하기 위해서 단위 테스트를 한 시간 동안 켜 두고 기다려야 하는 말도 안 되는 상황이 발생합니다. 

 

이런 상황을 위해서 저희는 유즈 케이스를 프로토콜로 한번 감싸 뷰 모델은 인터페이스만 알고 구체 타입을 알지 못하도록 했습니다.

이렇게요! 이렇게 구성하면 실제 앱에서는 내부가 로직으로 구현되어 있는 DefaultUseCase를 사용하고, 테스트에서는 유즈 케이스로부터 나와야 할 기댓값만 방출하는 MockUseCase를 사용할 수 있습니다. 

 

실제로 위 뷰 모델에서 실행시키는 타이머를 실행시키는 Mock 메서드는 아래와 같이 구성되어 있습니다.

원래는 여기서 실제 타이머를 실행시켜서 프로퍼티에 값을 계속 방출해야 하지만, Mock 객체는 테스트하고자 하는 10초, 그리고 49000초를 방출하고 종료됩니다. 

 

뷰 모델이 구독하던 값은 10, 49000이 들어오기 때문에 한 번의 요청으로 곧바로 10초에 대한 포맷 변환과 49000에 대한 포맷 변환이 가능해졌습니다.

 

Mock 

MockUseCase처럼 서로 의존 관계에 있는 레이어들은 모두 Mock레이어를 제공해서 기댓값을 무조건 방출하도록 하고 실제 테스트하고자 하는 레이어에 집중하도록 테스트를 설계했습니다.

 

이렇게 뷰 모델에 대한 테스트는 모두 Mock 유즈 케이스를 제공해서 Input과 output에만 집중하고, 유즈 케이스에 대한 테스트는 Mock 레파지토리를 통해 실제 비즈니스 로직에만 집중해 단위 테스트가 이루어지도록 할 수 있었습니다.

그래서 take(2) 왜 했냐고..

아까 슬쩍 넘어갔던 take(2)도 이제 설명할 수 있겠네요! 

 

이 타이머 메서드는 한 번의 실행만으로 10, 49000을 모두 방출하는데요,

 

이 단위 테스트에서 확인하고 싶었던 것은 MM:SS로 잘 바뀌는 지였고, HH:MM:SS는 별도로 테스트하고 싶었기 때문에 유즈 케이스에서 방출되는 초기값, 그리고 10초에 대한 값만 취해서 테스트하기 위해 take(2)를 사용했습니다..!

 

테스트 결과

일주일 동안 팀원들 모두 엄청나게 힘을 낸 덕분에 44개 중 43개에 대한 테스트를 모두 마쳤습니다.

뷰 모델은 이렇게 90% 이상의 코드 커버리지를 낼 수 있도록 테스트를 구성하고,

유즈 케이스도 일부 파일을 제외하고는 90% 이상의 코드 커버리지를 만들었습니다.

 

그리고 전체 파일에 대해서는

30%의 커버리지를 만들며 테스트를 종료했습니다.

 

마무리

단위 테스트를 진행하다 보니, 실제로 필요가 없는 함수인데 구현이 되어있는 경우도 있고, 파일 설계가 잘못된 경우도 발견할 수 있었습니다. 코드 커버리지를 높이기 위해 노력하면 부수적인 효과로 좋은 품질의 코드가 만들어지는 것 같습니다. 전체 코드 커버리지를 높이기 위해 레파지토리 영역까지 테스트를 해보고 싶은데 시간 상 할 수 없었던 점이 아쉽네요ㅠ

 

이렇게 Rx가 모두 처음인 우리 팀이 단위 테스트를 경험한 이야기를 공유해보았습니다. 테스트 코드나 프로젝트에 대해 더 궁금하시다면 깃허브에 방문해주세요! 감사합니다!

 

GitHub - boostcampwm-2021/iOS06-MateRunner: 함께 달리는 즐거움, Mate Runner 🏃🏻‍♂️🏃🏻‍♀️