TDD + Unit Test + Protocol(1)

배경

1. MovieRankApp은 단순한 기능을 구현하면서 현재까지 학습한 내용의 흐름을 적용함으로써 모르는 영역에 대해 확인하기 위해 진행된 프로젝트임.
2. 초안에서 기능 및 아키텍쳐, 라이브러리 사용 범위를 설정했었음.
3. 초안대로 MVC 패턴 - MVVM 패턴으로 구현이 순차적으로 이뤄졌으나, 보다 확실하게 디자인패턴을 이해하기 위해 기능을 추가하게 되었음.
4. 보다 발전적인 프로젝트 진행을 위해 동료에게 피드백을 요청하였으며, 피드백에 따른 기능을 추가하였음.
   • 기존: 최신 주간 트렌드 영화 목록 - 영화 선택시 영화 상세 정보 표시
   • 변경: 인기 영화 목록 - pagenation, Filter 기능 - 영화 선택시 영화 상세 정보 표시
5. 초기 개발 계획과 다르게 계속적인 변경사항이 발생할 수 있음을 인지하게 됨.
6. 요구사항의 추가는 기존 코드와의 충돌 가능성이 있기 때문에 이를 보완하기 위해서는 방법론을 고민함.
7. TDD의 경우, 추가 기능 코드에 대한 테스트 코드를 작성함으로써 기능에 대한 올바른 이해를 돕고, 기존 코드와의 충돌 가능성에 대해서 고려해볼 수 있는 장점이 있음.
8. 기존 코드에 대해서도 테스트 코드를 작성해봄으로써 놓치고 있는 오류를 재확인
9. 결국 TDD의 적용은 현재 프로젝트에 대한 안정성 및 코드 변경에 대한 유연성을 도와줄 것이라 판단됨.

---

TDD 적용

1. TDD(Test Driven Development) 테스트 주도 개발의 줄임말임.
2. 테스트 주도 개발은 설계 이후 코드 개발 및 테스트 케이스를 작성하는 기존 프로세스와 다르게, 테스트 케이스를 작성한 후 실제 코드를 개발하여 리팩토링 하는 절차를 따름
3. 현재 MovieRankApp의 작업 프로세스는 디자인 -> 코드 개발 -> 테스트에 해당하며, 현재 TDD를 적용하겠다는 말은 테스트 과정을 거친다는 말과 같음.
4. 애초에 지금 적용된 프로젝트에 TDD를 적용한다는 것이 아니라, 기존 코드에 대해 오류 여부를 판단하기 위해 Unit Test를 한다는 것이 적절함.

자문자답

Q. 그렇다면 현재 프로젝트의 경우 View 작성 후 View Model, APIManager를 구성하는 작업 순서를 가졌다. TDD 방식으로 작업한다면 동일하게 View부터 작업하는 것이 좋을까?

A. TDD는 테스트 코드 작성 후 통과된 코드를 작성한다. 어떤 것을 테스트하기 좋을까? 분명한 결과값이 나오는 것이 좋다.(예: 1+2 != 4) 그렇다면 데이터 처리에 대한 값이 예상된 값이 나오는 유무를 확인할 수 있는 View Model에 대한 작업이 선행되어야 할 것이다.

Q. View Model에 대한 Unit Test를 먼저 진행하려면 데이터가 명확하게 구성되어야 하는데 그렇다면 네트워크 통신(APIManager)에 대한 단위 테스트를 진행해야 할까?

A. Json 변경이 일어날 수 있기 때문에 명확한 값을 받고 Model에 넣는 것을 보장하기 쉽지 않을 것 같음.

Q. 그렇다면 View Model을 작업한다는 것은 결국 APIManager로부터 받은 데이터 Model에 대한 Method 작성인데, 이것을 어떻게 작성할 수 있다는 것일까?

A. Mock 데이터 - Model를 만들어 작업하면 된다.

5. 그래서 View Model의 Unit Test를 위해 Mock 데이터를 만들고자 함.
6. Mock 데이터의 경우 가상데이터를 만들거나, 현재 만들어진 APIManager의 의존성주입을 하여 구성할 수 있을 것이라 판단됨. 결합도를 낮춰 APIManager에 영향을 주지 않을 수 있음.

자문자답

Q. 의존성 주입을 통해 Mock 데이터를 만든다면 현재까지 코드에서 놓친 부분은 없을까?

A. 있음. ViewModel, APIManager, MainViewController에 각각 인스턴스를 생성했음.

7. 처음부터 테스트 적용할 수 있는 대상에 대한 Protocol 활용을 했더라면, 지금 하려고 하는 Unit Test를 수월하게 적용할 수 있음.

---

정리

1. MVVM의 아키텍쳐의 경우 ViewModel과 ViewController의 역할을 분명하게 구분함으로써 기능 추가시 내용을 쉽게 구분하여 코드 적용이 가능하도록 도움.
2. TDD, Unit Test, 의존성 주입의 경우도 개선을 진행하면서 큰틀에서 놓치고 있었던 부분을 알게 됨.
3. 먼저 테스트 코드를 통해 작은 기능 단위부터 코드를 작성했더라면 어땠을까?
4. 자연스럽게 Protocol을 사용해 결합도를 낮춰서 APIManager의 변경이 있더라도 View Model과 ViewController에 영향을 주지 않았음을 알게됨.
5. TDD, Unit Test, 의존성 주입에 대한 개념을 알고 있었지만, 그것의 대한 효용성을 크게 느끼지 못했음.(어렵다는 핑계를 대고 있음...)
6. 그러나 ViewModel의 분리 때처럼 코드의 개선을 진행을 통해 각 요소의 필요성을 느끼게 됨.
7. 내일은 먼저 각각 인스턴스 생성한 부분부터 수정을 하고, View Model 대해 Unit Test를 적용해봐야겠음.