[Backlog] 테스트코드 수정

[maxisneverthat]

Description

To Do

테스트 코드 작성, 특히 백엔드에서 Mock을 사용할 때 어느 정도 선을 잡는 게 참 어렵지. 이거 해결하는 핵심은 어떤 레이어를 테스트하느냐에 따라 mock 사용 여부와 범위를 결정하는 거야. 그럼 어떻게 하면 적당한 균형을 찾을 수 있는지 단계별로 설명해볼게.

1. 유닛 테스트: Mock을 적극적으로 활용해라

유닛 테스트에서는 하나의 함수나 클래스 같은 작은 단위를 검증하는 게 목표야. 이 레이어에서는 의존성(dependencies)을 전부 Mock으로 대체해서 해당 유닛만 테스트하는 게 좋아.

예를 들어, 서비스 레이어의 UserService 안에 있는 getUser라는 메서드를 테스트한다고 해보자. 이때 DB에 직접 접근하는 건 지양하고, 데이터베이스 의존성을 전부 Mock으로 대체하는 게 맞아. 이렇게 해야 외부 요인(네트워크나 DB 상태)에 의해 테스트가 흔들리지 않고, 오로지 getUser 메서드의 로직만 검증할 수 있거든.

Tip: Jest 같은 걸 쓴다면 jest.fn()이나 jest.spyOn()을 활용해서 필요한 부분만 Mocking하고, 정말 필요한 경우를 제외하고는 Mock을 최소화하려고 해.

2. 통합 테스트: Mock은 최소화하고 진짜 의존성 사용

통합 테스트에서는 여러 유닛이 조합되어 기능이 제대로 동작하는지 검증하니까, 가급적 실제 의존성을 사용하는 게 맞아. 예를 들어, UserService와 실제 DB 연결을 함께 테스트해서 데이터가 제대로 저장/조회되는지 확인하는 거지.

이때는 테스트 환경용으로 분리된 데이터베이스(예: 테스트 전용 PostgreSQL 컨테이너)를 사용해서 실제로 데이터를 넣고 빼면서 테스트를 진행하면 좋아. 이렇게 하면 실제 데이터 흐름과 유사한 상황을 시뮬레이션할 수 있어서 실용적인 테스트가 돼.

Tip: 통합 테스트에서는 Jest의 setupFilesAfterEnv 같은 설정으로 테스트 데이터베이스 초기화나 트랜잭션 처리를 자동화하는 것도 추천해. 테스트마다 DB 상태가 초기화되어야 서로 영향을 안 주니까.

3. E2E 테스트: 전체적인 흐름만 확인

E2E(End-to-End) 테스트에서는 API가 전체적으로 예상대로 동작하는지 검증하는 거니까 Mock을 거의 쓰지 않는 게 좋아. 오히려 실제 서버를 띄우고, 클라이언트와의 상호작용이 잘 되는지 확인하는 데 집중해야 해.

이 과정에서 AWS 서비스 같은 외부 API 호출을 테스트해야 한다면, 그런 부분은 가벼운 Mock으로 대체할 수 있어. 예를 들어 S3나 SNS와의 연동은 최소한의 성공/실패 케이스만 확인하는 식으로 제한하고, 대부분의 로직은 실제 인프라를 사용하는 게 맞아.

Tip: E2E 테스트가 너무 느리다면 테스트 전용 AWS 계정에 API 호출을 설정해서 속도를 유지하거나, 중요한 경로만 선택적으로 테스트하는 것도 방법이야.

정리하자면

1. 유닛 테스트: Mock을 최대한 활용해서 단위 로직에 집중
2. 통합 테스트: 실제 의존성을 사용해서 여러 유닛 간 상호작용을 검증
3. E2E 테스트: 전체 흐름을 검증하며 필요시 외부 API는 가볍게 Mock

Mock이 너무 많아지면 테스트가 "현실성"을 잃고, 너무 적으면 테스트 효율이 떨어지니까 레이어별로 균형을 잘 맞추는 게 핵심이야.

Reference