회고 : 두번째 프로젝트를 TDD로 진행하며... #1
첫번째 프로젝트 리뷰, 목표설정, TDD공부, UI 테스트
#시작하기 전에
이 글 은 진행했던 TDD프로젝트의 회고이다. TDD를 설명하는 글은 아니다.
기술적 노하우를 전달하는 글도 아니다.
브런치의 글은 카피가 안되고 소스코드를 첨부하기에 적절하지 않아 Medium 에 글을 같이 쓰려한다.
Medium의 글링크를 첨부한다.
첫번째 프로젝트의 리뷰
두번째 TDD공부를 위한 프로젝트를 시작하면서, 먼저 첫번째 진행했던 어썸 블로그 프로젝트 TDD에 대한 리뷰를 진행했다. 전체 소스코드 중 테스트 되지 않은 코드는 얼마나 되는지, 핵심 로직은 모두 테스트 되었는지 확인하고싶었다. UI 테스트는 뷰 컨트롤러 스크린샷 테스트만 했기때문에 테스트 되지 않은 코드가 많을 것으로 예상했고, Reactor 에 구현된 코드들은 모두 테스팅 되어있을 것을 기대했다.
우선 code coverage 를 살펴봤다.
( 주: code coverage 는 중요한 지표는 아니다. )
내부에 테스팅 되지 않은 코드들을 살펴봤다. 핵심부분들은 테스트 되었지만 ‘캐싱된 데이터를 먼저 보여 주는 기능' 등은 의도치 않게 테스트가 누락된 것들이 있었다. 또한 리팩토링 과정에서 삭제하는 것을 잊어 사용하지 않는 코드의 잔재도 여럿 있었다.
(리뷰하면서 발생한 코드 및 설계에 대한 반성은 덤)
코드리뷰를 하며 몇가지 문제점들의 원인을 생각해보고 다음 목표를 설정했다.
프로젝트의 목표
1. TDD 의 기본 원칙을 철저히 따르면서 공부하며 개발하기.
- 실패한 테스트 작성 -> 구현 -> 리펙토링
- 교육자료들을 좀 더 보고 기본을 더 탄탄하게 하자.
2. MVVM ( + Coordinator ) 구조로 만들어 보기.
- MVVM 에 대해 공부해 이해를 높이자.
- 개발자 ( or 회사) 들의 MVVM-C 오픈소스를 비교해보고 공부하자
- 구성된 요소들이 분리되어야 할 부분을 확실히 분리하는 연습을 하자.
3. UI 테스팅 코드를 모두 작성해 보자.
- 앱이 의도한 동작에 대한 결과를 미리 생각해보고 테스트 코드를 짜보자.
4. Code coverage 100%
( 중요한 지표는 아니다. 그저 한번 목표를 설정해본것 뿐이다. )
- 필요없는 코드 작성을 피하자.
- 모든 코드를 테스트 하자.
1. TDD 공부는 어떻게 할까?
https://www.raywenderlich.com/150073/ios-unit-testing-and-ui-testing-tutorial
https://academy.realm.io/posts/testing-in-swift/
https://anthonysciamanna.com/2015/04/18/ping-pong-pair-programming.html
여기까지는 지난 게시물에 링크한 것들이고,
MS 아카데미의 교육자료이다. 쉽고 재미있는(?) 동영상 강의이다. 짧은 재생시간으로 여러파트로 나누어져 있어 흥미를 잃지 않고 볼수있는 좋은 강의였다.
이규원 님의 블로그 글이다. TDD의 이점에 대해 Kent Beck 의 글이 번역되어있다.
2. UI 테스팅은 어떻게 할까?
iOS UI 테스팅에 대한 여러 글들이다.
링크의 내용 정리
XCUITest 의 한계점들에 대한 설명.
Uber의 iOS Snapshot TestCase 와 Google 의 EarlGrey 를 사용.
스냅샷 테스트 및 기능 테스트에 대한 설명.
coordinator 를 테스트 할때에는 uber의 ios-snapshot-test-case가 적합했다. coordinator 에 액션을 전달하고 presentation logic을 통해 결과로 기대된 view controller 의 스냅샷을 확인하면 되기 때문이었다.
이 부분은 MVVM-C 글에서 예를 들어 설명하려 한다.
스냅샷 테스트 오픈소스.
본래 FacebookSnapshotTest 이었는데 이제는 Uber가 관리하나보다.
UI 테스트는 Google 의 EarlGrey 를 사용했다.
EarlGrey 에 대한 학습을 별로 하지 않아도 간단하게 테스트 코드를 짤수있었다. 후에 복잡한 테스트케이스를 짜기 위해서는 공부를 해야하긴 했다.
샘플을 보면 쉽게 이해가 될것 같다.
브런치에서는 코드가 보기 힘들어서 gist 에 코드를 올려두었다.
물건을 입력하고, 삭제하는 것을 테스트한 코드이다. 중간에 한번이라도 fail이 발생하면 테스트는 실패한다. 코드가 유저 입력을 표현하고 있어 이해하기 쉽고 간결하다고 느꼈다.
이외에 스크롤을 해서 원하는 아이템을 선택하는 테스트 등도 쉽게 가능하다.
EarlGrey 는 객체를 찾을때까지 기다리고, 이후 로직이 실행되므로,데이터가 표현되는 것을 기다려야 한다던지 등을 신경쓰지 않아도 된다. (원한다면 time out 의 시간도 조정가능하다.)
( UI테스팅은 테스트 코드에 따라 차이가 있겠지만 기본적으로 객체를 찾고, 동작을 입력하는데에 시간이 걸리기 때문에 테스팅에 많은 시간이 소요된다.)
테스트를 실행한 모습EarlGrey 는 한글로 객체를 찾을때 아래와 같은 문제가 발생하기도 하니 참고하자.
추가로 아래는 쉽게 객체를 찾기 위해 커스텀 한 내용이다.
EarlGrey + facebook snapshot 을 위한 오픈소스도 있다.
3. Code coverage
다시 한번 언급하지만 code coverage 는 중요하지 않다. 모든 코드를 테스트하는 것도 필수가 아니다. 나의 경우 불필요한 코드의 작성을 막고 싶어서 선택해본 목표이다.
Xcode 에서 code coverage 설정방법.
Gather coverage for 옵션을 활성화 시키고 Target을 설정해 주면 된다.cocoapods 들을 code coverage 에서 제외하기 위한 방법
결과를 확인하는 방법.
위에서 각 파일별로 확인가능하며, 테스트 되지 않은 코드는 아래와 같이 표시된다.
중요한건 아니지만, XCode 에서 Code coverage 는 몇몇 부분에서 집계가 정상적이지 않기도 한다.
이 코드는 정상적으로 실행되었다.
하지만 이렇게 된다.
- 함수내 함수는 정상 집계하지 못하는 것으로 보인다.
- Array 의 reduce 를 사용해도 마찬가지로 정상적으로 집계되지 않았었다.
MVVM 에 대해 학습한 내용과 MVVM+C에 대해서는 별도의 글에서 정리하려 한다.
마침.
두번째 이야기
