이번 글에서는 테스트 코드에 대해 섣불리 도전하지 못하는 분들을 위해 테스트 코드를 작성하는 방법과 JaCoCo 테스트 커버리지 100%를 달성해보는 내용을 정리해보려고 한다.
필자도 이전까지 조금씩 테스트 코드를 살펴보거나 작성해본 적은 있어도 각 요소에 대해서 제대로 공부해보거나 모든 요소에 테스트를 작성해 본 적은 없었다.
인프런 워밍업 클럽 2기 - 백엔드 프로젝트(Kotlin, Spring) / 후기
최근에 인프런에서 진행하는 스터디에 참여하게 되었고, 스터디에서 진행한 프로젝트를 피드백 받을 수 있는 기회가 생겼다.
코치님은 테스트 커버리지 100%에 도전했을 때 분명히 얻게되는 게 있을 것이라고 하셨고, 이에 도전하게 되었다.
테스트 코드에 관한 내용은 생각은 생각보다 더 다양하다.
하지만 중요하지 않다는 말은 어디에서도 볼 수 없으며, 중점을 두는 부분이 달랐던 것 같다.
이러한 테스트 코드는 단순히 기능 내에서 발생할 수 있는 오류를 사전에 검사할 수 있다는 이점 말고도 여러 이점이 존재한다.
아래 책의 내용에서 아래와 같은 내용이 있다.
구글도 초창기에는 엔지니어에 의한 자동 테스트를 그다지 중요하게 생각하지 않았다. 그러나 2005년에 구글 웹 서버(GWS) 규모와 복잡성이 무척 커지면서 생산성이 급속도로 떨어지는 경험을 했다. 릴리즈 때마다 버그가 넘쳐났고 다음 릴리즈까지의 길이는 무한정 늘어났다. 서비스를 수정해야 할 때마다 팀원들은 불안해 했고 프로덕션 환경에서만 기능에 영향을 주는 버그도 너무나 자주 발생했다.
구글 테크리드는 엔지니어 주도의 자동 테스트를 정책 차원에서 도입하기로 결정했다. 결과적으로 1년만에 긴급하게 코드를 수정해 배포하는 건수가 '절반'으로 줄었고 이와 동시에 연중 처리 완료하는 이슈 개수도 계속해서 증가하는 추세가 되었다.
구글에서도 테스트를 중요하게 생각하지 않았지만, 서비스를 수정하고 릴리즈 할 때마다 팀원들이 불안에 떨었고, 이를 해결하기 위해 자동 테스트를 도입하게 되었다.
자동 테스트 도입 이후 팀원들은 자신감있게 배포할 수 있게 되었고, 생산성이 늘어나게 되었다고 한다.