들어가기 앞서
이 포스팅은 DOKBARO를 개발하면서 경험한 것을 기반으로 제작하였습니다.
DOKBARO란 ?
자기계발과 성장을 위해 독서와 스터디를 활용하는 개발자들을 위한 퀴즈 학습 플랫폼, DOKBARO입니다.
개발 서적을 즐겨 읽지만, 매번 내용을 제대로 이해했는지 확인하기 어렵지 않으셨나요? 혹은 이해 부족으로 인해 독서 스터디가 소수만 적극적으로 참여하는 형태로 변질되는 경험을 하셨을지도 모릅니다.
그래서, DOKBARO는
📚 퀴즈 출제 및 풀이 기능으로 도서 내용을 재미있고 효과적으로 이해하도록 도와드려요.
💡 스터디 리포트 기능으로 스터디원들이 책에 대해 자유롭게 의견을 나누고, 서로의 학습 현황을 확인할 수 있어요.
DOKBARO와 함께라면 도서 이해도를 높이고, 스터디 활동을 보다 풍성하고 활발하게 만들어 이상적인 독서 환경을 경험하실 수 있습니다. ✌️
현재 베타 오픈중이니 아래 링크를 통해 이용해보실 수 있어요!
https://dokbaro.com
기존 회사 테스트 방식
전 회사에서는 다음과 같이 테스트를 진행했습니다!
1. 브라우저에서 curl 복사
- postman에다가 붙여넣기
- 실행
이렇게 UI 단에서 테스트를 진행하고 있었습니다! 자그마한 수정을 해도 이를 검증하기 위해 UI단에서 직접 실행해야만 했고,
특히 기능 변경시에 변경에 따른 타 컴포넌트의 영향력을 알 방법이 없었습니다.
굳이 curl 복사하지 않고 postman으로 바로 요청하면 되는거 아니야?? 하시는 분들도 분명 있으실겁니다!
허나, API 당 파라미터가 기본 30개 이상인 API 도 많았어서 수기로 직접 요청을 보내기에는 무리가 많았던 환경이었습니다...ㅎㅎ
내 서비스 만큼은 저렇게 키우지 말아야지
회사 업무를 통해 단위 테스트의 필요성을 절실히 느낀 저는 이번에 진행하는 프로젝트 만큼은 단위 테스트를 신경써서 하기로 결심했습니다.
그래서 모든 부분에 대해 테스트를 진행하자! 라는 마인드로 커버리지 100 달성을 목표로 애플리케이션을 개발하였습니다.
이런 식으로 kover을 통해 커버리지 100% 제한을 설정했고,
jenkins 빌드 시에도 kover verify를 실행시켜 커버리지가 충족이 안되면 빌드가 불가능하도록 구현했습니다.
장점
커버리지 100% 달성 겸, 전반적인 단위테스트 진행시 느꼈던 점을 기술해보겠습니다.
1. postman은 켠 지가 언제였더라...
일단 UI 테스트 없이 개발을 할 수 있다는 기쁨을 느낀게 너무 오랜만이었습니다 ㅠㅠ
메서드단위로 바로 잘못된 부분을 검증할 수 있어서 맘 편하게 개발할 수 있었습니다! 마치 게임하면서 중간중간 세이브하는 느낌이랄까요
2. 기능 변경 / 리펙터링 시 안정성 확보
기능 변경 시 어디까지 변경사항이 전파되었는지, 또 리펙터링 시 혹시라도 애플리케이션이 망가지지 않았는지 검증하기 너무 쉬웠습니다
3. 계층 테스트도 탄탄해!
현재 DOKBARO는 rest doc을 활용해 test를 통한 API 문서를 자동화하고 있는데요!
커버리지를 적용해서 모든 API에 대해 문서를 강제로 제공하여 문서 누락이 안되는 결과를 얻었습니다!
또한 DB 계층에서도 입력값과 출력값이 요구한대로 나오는지 확실히 알 수 있었습니다.
문제점
과유불급(過猶不及)이라고, 막연히 100%를 달성했다고 마냥 좋지는 않았습니다. 그럼 어떤 부분에서 아쉬웠는지 기술해보겠습니다.
1. 단순한 로직이여도 테스트를 추가해야 함
단순한 CRUD나 BY pass 로직 같은 경우, 아니면 진짜 사소한 라인 하나가 발목을 잡는 경우도 많았습니다.
이런 부분까지 커버하기위해 테스트를 진행해야하는 귀찮음이 있었습니다.
2. 구멍이 없을 것 같아?
결국 커버리지는 코드로 표현한 것 내에서 계산을 진행합니다. 즉, 코드로 표현되지 않은 요구사항은 커버리지에 반영되지 않습니다.
커버리지가 100% 이라고 해서 원하는 의도대로 설계했다고 볼 수 없었습니다.
3. DB 레벨 계층 테스트는 100% 보장할 수 없다
kover 혹은 intellij 커버리지 기준으로는 DB 내 where 분기 등은 커버리지를 확인할 수 없었습니다.
이 부분은 별도로 다각화해서 테스트를 진행하였습니다
향후 진행 방식
호기롭게 시작한 커버리지 100% 목표가 프로젝트가 경과될수록 그 가치에 대해 의문점을 많이 가졌는데요!
위 언급한 장점이 꼭 커버리지 100% 여야만 느낄 수 있는 건가 생각해보면...지금 다시 생각해 봤을 때 아닌 것 같다는 느낌이 듭니다.
다음에도 신규 프로젝트를 진행할 때도 커버리지 100%을 설정할 것이냐 묻는다면... 고민을 많이 해볼 것 같습니다.
허나 단위테스트에 대한 필요성과, 그로 인해 얻은 이점은 커버리지 달성에 대한 귀찮음보다 크게 느껴졌기에,
꼭 커버리지 방식은 아니더라도 단위 테스트를 체계화 할 수 있는 방안을 생각할 수 있을 것 같습니다.
마무리
커버리지가 100% 여서 버그가 존재하지 않았을까요? 전혀 그렇지 않습니다.
저희 다 코로나 백신 맞고도 코로나에 걸린 것 처럼, 단위테스트로 커버한다고 해서 결점이 없는 것은 아닙니다.
허나 테스트를 통해 점진적으로 버그를 예방할 수 있다 생각합니다. 또한 체계적인 테스트가 있어야 서비스가 성장 속도를 유지할 수 있다 생각합니다.
테스트 또한 문서라 생각합니다! 즉, 단순히 커버리지를 채우기 위한 어떠한 알멩이 없는 반복된 부분보다는,
해당 컴포넌트를 설명할 수 있는 테스트가 좋은 테스트라 생각합니다! 단순히 양으로 승부하는 것 보다 질로 승부하는 단위 테스트가 더 가치 있게 느껴졌습니다.
테스트 커버리지 도구는 테스트에서 누락된 부분을 검증할 수 있기에 양과 질 둘 다 잡을 수 있는 도구라 생각합니다.
허나 도구에 사로잡혀 본질을 알지 못한다면 도구를 효과적으로 사용할 수 없을 것 같습니다.
커버리지 도구를 상황에 맞게 활용해서 서비스의 테스트를 더 나은 방향으로 설계할 수 있을 것이라 생각합니다.
