🙋🏻 개요

이번 프로젝트를 진행하면서, 테스트 코드를 제대로 짜보기로 기획하였다. 따라서 한 메소드가 완성 될때마다, 동작하는 지 여부를 확인하기 위한 테스트 코드를 짜면서 발생했던 문제점들과 해결법들을 적어보고자 한다.

1. 테스트가 실제 DB에 영향을 주는 문제 발생

// 메시지를 저장할 메시징 큐
private val messageQueue: BlockingQueue<CommandChatMessageRequestDto> 
= LinkedBlockingQueue()

// 메시지 전송
val messageDto =
CommandChatMessageRequestDto(
sender = "Alice",
chatRoomId = chatRoomId,
message = "안녕하세요, Alice22입니다.",
messageType = CommandChatMessageType.CHAT,
)

session.send("/app/$chatRoomId", messageDto)

// 메시지 정상 전달 여부 확인
val receiveMessage = messageQueue.poll(5, TimeUnit.SECONDS)

기존 테스트 코드에서는 위 방식처럼 직접 기존 경로를 통해서 메시지가 전송되는 것을 확인하기 위해, send()를 사용하여 실제 구독 경로로 메시지를 전송하였고, 해당 경로를 구독 중인 사용자들에게 전송되어 실제 DB에 저장되었다.
하지만, 테스트 과정이 실제 환경에 영향을 미치면 안되므로, 메시지를 전송해도 실제 DB에 영향을 미치지 않고, DB에 잘 저장이 되는지를 확인하기 위해서 다른 방식을 사용하였다.

2. 해결과정

1. Embedded-MongoDB 적용하기

실제 DB환경에 영향을 주지 않고, 테스트 코드만을 위한 DB를 만드는 방식을 알아보니 대표적으로 2가지가 존재하였다.

1.Embedded MongoDB: Java 애플리케이션 내에서 Embedded MongoDB를 실행

• 장점: 빠른 실행 속도/ 설정 쉬움
• 단점: 실제 운영환경과는 다를 수 있음 / MongoDB의 고급 기능(샤딩, 트랜잭션 등) 제공 X / 병렬 테스트 어려움

2.TestContainer MongoDB: Docker 컨테이너에 MongoDB를 만들어서 실행

• 장점: 실제 운영환경과 동일한 MongoDB 사용 / 테스트 환경 일관성 유지 / 병렬 테스트 가능 / MongoDB 고급 기능 제공 O
• 단점: Docker 필요 / 테스트시 컨테이너 시작 시간이 추가됨 / 설정 복잡

위와 같은 장단점을 가지고 있는 2가지 방식이 있었고, 우리 프로젝트의 특성을 대입하여 봤을때, CI/CD시에도 크게 문제가 없고, 운영 하는 과정에서 장애가 적은 "TestContainer MongoDB"를 사용하기로 결정하였다.
추가적인 조사와 실험을 해본 결과 TestContainer는 서버를 실행시에는 container를 새롭게 만들어야 하기 때문에 시간이 많이 소요되었다. 따라서 운영 검증 시에 Test Container를 사용하기로 결정하였고, 빠른 속도가 중요한 단위 테스트에는 Embedded-MongoDB를 사용하기로 결정하였다.