상황
실무 경험은 없지만 프로젝트 경험들을 통해 Test를 작성하지 않은 경험, Dependency를 제거하여 Mockito를 활용한 Test 방식, Repository Layer 즉 Database를 접근하는 단계까지 포함한 Test들을 경험해봤습니다.
테스트 코드에 대해 많은 의견들이 있고 중요성을 개발자들이 강조하지만
이론으로 접하는 것과 직접 작성하면서 얻는 경험은 다르다고 생각합니다.
문제
간단한 비즈니스 로직, 쿼리문만 존재하는 로직, 의존성을 가지고 있는 로직 등등 다양한 스타일의 로직이 존재합니다.
간단한 로직이고 많이 해봤으니까 문제 없겠지? 버그가 생길 일이 없어.
라고 단정지은 경험 있지 않으신가요?
이런 자신감에서 비롯되는 버그는 필연적으로 존재한다고 생각합니다.
개발이라는 것은 '혼자'서도 하겠지만 보통은 '팀' 의 단위로 작업하기 때문에 모든 상황들을 스스로 인지하고 있지 못할때가 많기 때문이라고 생각합니다.
문제1
테스트 코드를 작성하지 않으면 유지 보수 비용이 더 든다.
정말 무지했던 시절, Postman을 이용해 하나하나 API 호출을 해보며 테스트 했습니다.
빌드하고... 배포하고 .. (시간 비용이 어마어마 합니다)
문제2
다양한 상황들을 만들어가며 테스트하기 힘들다.
다양한 케이스 들이 존재할텐데, 하나하나 요청하면서 테스트를 할 것인가? 에 대해 막막합니다.
상황을 애플리케이션 코드 레벨에서 관리하고 유지보수한다면 비용이 그만큼 줄어든다고 생각합니다.
문제3
Behavior, Status
개발자가 작성한 로직에서 발생해야할 행위와 상태 -> 예상한대로 동작하는가?
테스트 코드를 작성하지 않으면 검증하기가 매우 힘듭니다.
이러한 경험을 통해 테스트 코드의 이점을 느낄 수 있었습니다.
결과
다음으로는 실제 프로젝트에 참여하며 테스트 커버리지 유지를 해봤던 경험을 소개하고자 합니다.
개선된 점1
해당 프로젝트에서는 Unit Test라기 보다 실제 Database까지 접근하여 테스트하는 통합 테스트에 가까운 방식을 채택했습니다.
의존성이 제거된 테스트 방식이 아니라 실제 결과물을 보여주기 때문에 내가 작성한 코드에 대한 신뢰도가 대폭 올라갔으며 높은 커버리지를 통해 팀원들과 생산성 있는 리뷰를 경험했습니다.
개선된 점2
테스트 코드는 비즈니스 로직이 어떻게 동작하는지에 대한 이해도도 높여준다는 것이었습니다. 상황 설명과 테스트에 활용되는 인스턴스 상태와 행위를 직접 확인하면서 리뷰의 즐거움을 느낄 수 있었습니다.
더 나아갈 점
시간에 쫒기는 프로젝트를 하다 보니, 사실 소나큐브 지표 그래프가 예쁘지가 않습니다. 테스트를 먼저 작성하고 개발을 해보는 경험도 필요할 것 같습니다.
- 나는 Unit Test를 잘하고 있을까?에 대해서도 고민하고 성장하고자 합니다. 런던파, 고전파의 견해를 책에서 읽어본 적이 있는데 아직 갈길이 멀다고 생각합니다...
- 테스트 코드에서 활용되는 Fixture를 잘 활용할 수 없을까? 초기에 전역으로 사용하면서 Fixture의 상태가 변경되며 테스트 코드의 실패를 겪었던 케이스들도 있었습니다.
테스트 코드에 많은 시간 비용을 투자해야 성장한다고 생각합니다.
