2025. 3. 25. 12:39ㆍ개발
🚩 문제 상황
프로젝트에서 하나, 둘 씩 테스트가 늘어가며 문제가 발생했다!
1분 이하였던 테스트들이 4분을 넘어가기 시작했다.
(실제로는 실행시간에 포함되지 않는 과정까지 영상으로 확인했을 때 5분 정도 되었다)
테스트는 기능을 추가하고 수정하며 빠른 피드백을 얻기 위함이었는데, 깃허브 액션 환경에서는 20분이 걸리기도 하여 협업 효율을 낮춘다고 생각이 들었다.
개선하고자 로그를 살펴봤다.
크게 보이는 문제는 두 가지였는데
- 각 테스트마다 컨텍스트 빌드 시간이 길다는 점
- 데이터베이스의 쿼리문이 테스트 시간의 대부분을 차지한다는 점
🛠️ 1. 컨텍스트 환경 통합시키기
이전에 MockBean을 사용하며, 테스트 환경 캐싱으로 인한 충돌로 골머리를 앓았지만, 그때 어플리케이션 컨텍스트가 캐싱으로 재사용 가능하다는 것을 알게 되었다.
"컨텍스트 환경을 통합하여 캐싱한다면 최소한의 빌드로 테스트가 가능하지 않을까?"
현재 프로젝트 테스트에는 2가지 컨텍스트 환경이 필요했다.
- RestDocs용 테스트 환경
- 통합 테스트 환경 + 웹소켓 테스트 환경
RestDocs의 경우 컨트롤러를 SpyBean으로 사용하며 모킹하고 있었다. 컨트롤러 간 의존관계가 없었기에, 테스트마다 사용하는 SpyBean 컨트롤러를 BaseRestDocTest 클래스에 모두 등록한 뒤, 각 테스트에서 상속받도록 하여 환경을 통합할 수 있었다.
통합 테스트 환경 역시 외부 리소스를 막기 위해 모킹했던 각 SpyBean들을 BaseIntegrationTest에 선언해두고 상속받아 같은 환경을 유지했다.
결과적으로 더 많은 테스트를 실행했음에도 실행시간을 3분대로 낮출 수 있었다!
(실패한 테스트의 경우 해당 이슈와는 관련이 없는 관계로 잠시 넘어가겠다.+ 이미 해결됐다.)
🚀 2. 외부 DB를 임베디드 DB로 변경
기존 테스트에서는 외부 RDS와 연동하여 진행하고 있었다. 이전 DB 성능 측정 경험을 떠올려봤을 때, 쿼리가 느린 이유가 네트워크 비용 때문이라 생각했다.
또한 외부 리소스 상태에 따라 테스트 결과가 달라지고, 여러 명이 동시에 테스트하면 충돌이 발생하는 등 외부 RDS 사용이 적절하지 않다고 판단했다.
"임베디드 DB를 사용하면 네트워크 리소스가 줄어들고 외부 환경에 독립적이지 않을까?"
h2 데이터베이스를 임베디드 DB로 사용한 결과는 다음과 같았다!
28초! 빠르게는 22초까지 나왔는데, 30초 내라면 기능 구현, 수정 후 빠른 피드백을 받기에 충분한 시간대라고 생각했다.
깃허브 액션을 사용한 CI/CD과정에서도 기존 20분에서 2분내로 테스트가 끝나는 것을 확인할 수 있었다!
어쩌면 테스트 환경을 고민하던 시점부터 외부 자원의 의존성을 낮추기 위해 임베디드 DB 환경을 택하지 못한점은 아쉬웠으나, 문제 상황을 분석하고 해결해본 경험도 나름대로 의미가 있었던 것 같다.
'개발' 카테고리의 다른 글
프로젝트에서 채팅을 구현한 방법 - 채팅 기능 문서화 (0) | 2025.03.25 |
---|---|
배포 오류 : Asciidoctor 빌드 오류(asGemPath()) (0) | 2025.03.09 |
CI/CD : 테스트 실패시, Push 안되게 하기 (0) | 2025.03.09 |
CI/CD : Github Actions를 이용한 배포 자동화 (0) | 2025.03.09 |
Mock : 모의(대역) 객체로 테스트하기 (0) | 2025.03.08 |