앱 개발시 유닛테스트에 대한 생각과 경험
앱 개발시 유닛테스트에 대해 제 경험과 생각을 공유 드립니다. 유닛테스트를 언제, 어떻게 사용할지 감을 잡으시는데 도움이 되면 좋겠습니다.
1. 유닛테스트, 통합 테스트, UI 테스트 사용 경험은? → 유닛테스트만 사용해봤습니다.
2. 유닛테스트는 꼭 써야 할까? → No!. 필요한 경우에 한해 사용하는 것이 합리적이라고 봅니다. 그동안 다양한 개발자들과 일했는데, 유닛테스트를 사용하는 개발자는 저 포함 10% 이하 였습니다.
3. 유닛테스트를 사용하지 않는 이유는?
- 테스트 코드 작성 대비 효율이 낮음
- 테스트를 위해 아키텍처나 코드를 변경해야 하는 경우가 많음
- 비즈니스 가치 증대를 위해 코드를 작성하는게 아니라 테스트 코드 작성을 위해 코드를 변경해야 한다고? 주객이 전도 된건 아닐까?
- 유닛테스트 유지보수 투여되는 자원이 부담됨
- 코드를 변경하면 많은 경우 유닛테스트가 에러나서 유닛테스트 코드도 함께 변경해야 함
- 테스크 코드 작성을 위해 앱 구조를 바꾸더라도 테스트하기 어려운 케이스는 여전히 존재함
- 결국 사람이 손으로 테스트해야 하는 상황은 피할 수 없음
종합: 작성에 시간이 많이 들고, 유지보수에 노력이 들고, 어떤 경우 테스트 코드 작성이 매우 어려움. -> 그래서 저는 필요한 경우에만 사용했습니다.
4. 테스트 커버리지는 몇 %가 적당할까? → 특정 퍼센트를 목표로 하기보다는 필요한 부분에만 적용하면 된다고 생각합니다. 예를 들어, 전체 코드 중 5%만 테스트가 필요하다면 그 5%만 테스트해도 충분하다고 봅니다.
5. 유닛테스트가 필요한 경우는 언제일까? (feat: 나는 언제 유닛테스트를 사용했나?) → 중요한 로직이면서 테스트 해야하는 케이스가 많고, 테스트가 비교적 쉬운 경우에 유용하다고 생각합니다. 저는 다양한 입력 조합에 따라 결과가 달라지는 중요한 로직의 검증에 유닛테스트를 활용했습니다. 회사 근무 마지막 5년 동안 유닛테스트를 사용했던 경우는 세 번 있었습니다. 그 사례는 아래와 같습니다.
(사례1) 예약서비스 날짜/시간 표시 로직 검증 예약 서비스 개발 시 날짜는 사용자가 정확한 이용 시점을 인지하는 데 중요한 정보입니다. 비즈니스 요구 사항은 날짜를 오늘을 기준으로 조건에 따라 “상대적인 날짜 혹은 절대적인 날짜로 표시해 달라”였습니다. 이 조건을 충족시키기 위해 유닛테스트를 사용해 구현한 코드의 로직을 검증했습니다. [사례]
- 오늘을 기준으로 2일 이하 차이 나는 경우 -> 상대적인 날짜로 표시
- 어제, 그제, 오늘, 내일, 모레
- 오늘을 기준으로 2일을 초과해 차이 나는 경우 -> 절대적인 날짜로 표시
- 2050년 5월 20일, 2050년 5월 19일
(사례2) 이동 예상 요금 계산 로직 리팩토링 후 검증 이동 서비스(예: 택시)의 예상 요금은 사용자에게 중요한 정보입니다. 요금에 따라 이동 수단을 선택하기도 하고, 예상 요금과 실제 청구된 요금이 차이가 크면 컴플레인을 하거나 서비스에 대한 신뢰가 떨어질 수 있습니다.
예상 요금을 계산하는 로직에 다양한 조건이 지속적으로 추가되면서 요금 계산 로직이 점점 복잡해졌습니다. 결국 요금 계산 코드를 정리하는 리팩토링을 진행했고 코드 변경 후 기존 로직과 동일한 결과를 보장하기 위해 유닛테스트를 수행해 검증했습니다.
[예상 요금 계산 시 고려된 요소들]
- 호출비 (이용하는 이동 수단의 종류에 따라 다름, 할인/무료일 수도 있음)
- 운행 요금 (일반, 할증)
- 통행료
- 쿠폰 (정액, 정률)
- 기타 다양한 조건
유닛테스트 없이 리팩토링을 진행했다면 50개가 넘는 조합이 만들어지는 예상 요금 계산 코드를 올바르게 작성했는지 확신하기 어려웠을 것입니다. 하지만 유닛테스트를 통해 결과 값을 검증할 수 있었기 때문에 안심하고 리팩토링을 마무리할 수 있었습니다.
(사례3) 광고 코드 생성 로직 특정 화면에서 이용 중인 이동 수단과 결제 수단에 따라 배너 광고를 다르게 노출해달라는 요청이 있었습니다. 광고는 회사의 주요 수익원 중 하나였고, 잘못 노출될 경우 광고팀은 물론 광고를 의뢰한 외부 클라이언트에게도 소명을 해야하는 번거로운 상황이 생길 수 있었기 때문에, 오류 없이 정확하게 처리하는 것이 중요했습니다.
광고 배너를 노출하기 위해서는 서버로부터 배너 코드를 수신해야 했는데, 이를 위해 이동 수단과 결제 수단의 종류, 알파/리얼 환경 여부를 파라미터로 전달해야 했습니다. 이렇게 생성 가능한 파마미터의 조합 많아지는 상황이었기 때문에, 조건에 따라 올바른 광고 배너 코드가 생성되는지 검증하는 일이 중요했습니다.
테스트한 조건 예시:
- 이동수단A/결제타입1/알파
- 이동수단A/결제타입1/리얼
- 이동수단A/결제타입2/알파
- 이동수단A/결제타입2/리얼
- 이동수단B/결제타입1/알파
- 이동수단B/결제타입1/리얼
- …
이러한 로직은 유닛 테스트를 활용하면 안정적으로 검증할 수 있을 것이라 판단했고, 실제로 다양한 조건에 대해 테스트를 수행해 광고 코드가 정확하게 생성되는 것을 확인할 수 있었습니다.
6. 개인 프로젝트에서의 유닛테스트 경험 API EndPoint가 30개 이상이고 데이터 모델도 많은 개인 프로젝트를 진행하면서, QA 시간을 줄이고 안정성을 확보하고자 테스트 커버리지가 80% 이상이 될 정도로 많은 테스트 코드를 작성했습니다. 이렇게 테스트 작성에 시간을 많이 들였는데, 프로젝트는 결국 성공하지 못했습니다. 만약 지금 다시 한다면, 유닛테스트 작성은 줄이고 필요한 부분에만 최소한으로 작성했을 것 같습니다.
결 론
유닛테스트는 필요할 때 적절히 사용하면 매우 유익한 도구라고 생각합니다. 이상으로 저의 앱 개발시 유닛테스트에 대한 생각과 경험이었습니다.
즐코하세요~ 😄
