💡 개요
예전에 작성한 일기에서 H2에 Point 타입을 사용할 수 없어서 어쩔 수 없이 테스트 코드 동작에도 DB를 MySQL을 사용했다.
근데 이게 맞을까..? 단위 테스트의 목적은 빠르게 각각의 메서드를 테스트하는 것인데..
MySQL을 사용하면 어쩔 수 없이 인메모리 DB인 H2보다 느릴 수 밖에 없잖아..
현업에서도 테스트 코드를 동작할 때 실제 서버에서 사용하는 DB를 사용할까?
🛠️ 테스트용 DB == 실제 서버 DB
결론부터 말하면 상황에 따라 다르다고 한다.
⚙️ 단위 테스트는 빠르고 가볍게
단위 테스트는 여러 메서드를 나눠 검증하는 테스트이다.
이런 테스트에는 DB가 필요 없는 경우도 있다.
그래서 실제 DB 대신 H2와 같은 인메모리 DB을 사용하거나 Mocking을 사용해 Repository을 대체하는 경우도 있다.
→ 근데 난 Repository을 Mocking하는건 별로 안좋아한다.. 뭐랄까 너무 가짜로 하는 느낌..?
하지만 나한테 발생한 문제는 H2에서 Point와 같은 특별한 데이터 타입을 사용할 수 없는 상황이 발생할 수 있는 것이다.
이럴 땐 MySQL을 사용해도 괜찮겠지..?
→ 맞다. 괜찮다. 어쩔 수 없으니까.. 현업에서도 단위 테스트를 실행할 때 MySQL와 같은 DB을 사용하는 경우도 더러 있다고 한다.
⚙️ 통합 테스트는 실제 환경에 가깝게
통합 테스트는 또 다르다.
단위 테스트는 하나 하나의 메서드를 나눠 테스트하는 것이라면, 통합 테스트는 엮어있는 모든 메서드를 흐름에 맞게(Controller → Service → Repository) 동작시키는 테스트이다.
그렇기 때문에 배포 환경의 DB와 동일하게 설정한 후, 테스트하는 것이 적합하다.
그래서 최근에는 Testcontainers 같은 도구를 사용해 Docker 기반의 MySQL 컨테이너를 테스트 시작 전 자동으로 띄우고, 테스트가 끝나면 자동으로 내리는 방식이 사용된다.
'개발 일기' 카테고리의 다른 글
[개발 일기] 2025.06.19 - Constant 클래스? (0) | 2025.06.19 |
---|---|
[개발 일기] 2025.06.18 - Testcontainers (0) | 2025.06.18 |
[개발 일기] 2025.06.16 - Redis Bloom Filter (0) | 2025.06.16 |
[개발 일기] 2025.06.15 - 가상 스레드 (1) | 2025.06.15 |
[개발 일기] 2025.06.14 - 단위 테스트 → 통합 테스트 (0) | 2025.06.14 |