[React Native] RN 앱에 TDD 적용하기 1 - React Native TDD PoC

처음 개발을 시작할 때는 그저 '방법론'에 불과했던 TDD는 이제 개발 언어나 프레임워크를 막론하고 사용자에게 보다 우수한 품질의 서비스를 제공하기 위한 필수적인 '개발 과정'이 되어가고 있다. 내가 개발하고 있는 앱도 신규 버전을 계속 업데이트 하면서 새로운 기능 때문에 기존 기능에서 충돌이 나는 경험도 있었는데, 이미 테스트가 된 기능이니 신규 feature로 나가는 부분만 테스트하고 기존 부분에서는 테스트하지 않고 배포했기 때문에 발생했던 이슈였다.

 

물론 TDD에 대해 고려하지 않았던건 아니다.

해야하지만, 테스트 코드를 작성하는 시간에 요구사항을 더 쳐내야지 하는 생각에 나중으로 계속 미뤄왔었다.

더이상 이러한 나태함에 빠지지 않기 위해 블로그에도 정리해가며 TDD 도입을 완료할 생각이다.

 

이번 포스팅에선 TDD 도입에 대한 장/단점을 간단히 정리해보고, 어떤 부분부터 진행해야 할 지 다뤄보자.

 

👍 TDD 도입으로 인한 장점

컴포넌트를 설계할 때 용이하다.  
🤔 기능 구현 후 테스트가 아닌, 기능 구현 전부터 테스트 케이스를 작성하기 때문에 컴포넌트가 어떤 기능이 들어가야 하는지 명확하게 설계할 수 있다. 

 
신규 기능 또는 유지보수에 탁월하다.
🤔 코드 품질이 높아지는 것은 자연스러울 것이며, 기존 컴포넌트에 신규 기능을 넣을 때 기존 코드와의 연관성을 자동으로 테스트하기에 신규 기능이 추가될 때마다 일일이 사람이 처음부터 테스트하지 않아도 된다.  

 

코드 리뷰 시간을 단축시킨다
🤔 테스트가 통과된 코드를 PR하면 리뷰어는 해당 코드의 동작에 대해 고민할 시간이 단축되고, 테스트 케이스가 명확하게 보이므로 요청자가 어떤 의도를 가지고 코드를 작성하게 되었는지 알 수 있어 이에 해당하는 시간적 비용이 줄어들 것이다.

 

👎 TDD 도입으로 인한 단점

높은 초기 비용을 무시할 수 없다 
🤔 TDD를 사용하지 않고 이미 많은 기능을 가지고 있는 앱일수록 초기 설정하는 데 드는 비용이 많이 든다. 테스트 자동화도 결국 개발자가 직접 케이스를 작성하는 행위이며 수많은 라이브러리와의 의존성도 고려해야 하는 부분이다. 또 jest 지식에 대한 학습 비용도 들기 마련이다.  
🤔 테스트 코드를 작성하는 시간을 결코 무시할 수 없다. 1시간이면 마칠 일을 적어도 몇 배의 시간이 더 소요될 것이다.

✅ 결론  
➡️ 테스트 코드를 거치지 않고 배포된 버전에서 오류가 존재할 경우, 이 오류가 발견될 때까지의 시간이 오래 걸릴수록 버그픽스의 비용 또한 증가할 것이다. 사용자가 직접 버그를 발견하면 그 사용자는 과연 앱을 계속해서 사용하고 싶을까?  
➡️ 초기 세팅부터 모든 테스트 코드를 작성하려고 하지 말자. 간단한 알고리즘이 들어간 함수부터 차근차근 도입하여 익숙해지자.

✅ Action Item

✔️ jest PoC
✔️ 자주 사용하는 공용 함수로 TDD 시작해보기