[스프링+코틀린] mock 없이 통합 테스트하기

단위 테스트 책을 읽고 비즈니스 로직의 흐름을 담당하는 service layer(비즈니스 로직 흐름을 담당하는 layer) 테스트 코드를 시도했던 내용을 담는 포스팅입니다.

단위 테스트 - 예스24

배경

제가 시도 및 고민했던 부분은 다음과 같습니다.

1. mock을 어디까지 쓸 것인가

2. 조회 테스트 필요 유무

3. repository 테스트 필요 유무

1. mock을 어디까지 쓸 것인가

단위 테스트 책에서 보면 mock의 사용을 최소화하라고 나와있습니다.

초반 부분만 봤을 때에는 비즈니스 로직에 대한 테스트에만 사용을 지양하라고 이해해서 service layer에 Mocking을 왕창 했었습니다. 

허나, 책 후반부 통합 테스트에서의 예시에서 또한 mock은 최소화를 권장하고 있더군요.

외부 의존성(해당 애플리케이션 내에서 어찌할 수 없는 부분)을 mock하라고 나와 있습니다.

예시로는 외부 시스템 연동(슬랙, 결제 등)이 있습니다.

MSA 구조라면 다른 도메인 서비스 API 호출도 해당됩니다.

데이터베이스는 애플리케이션 내에서 어찌할 수 있는 부분이므로 mock을 최대한 지양하면서 통합 테스트 코드를 작성했습니다.

[1-1]. mock을 사용하지 않기 위해 @Sql로 데이터 구축

@Sql 어노테이션을 사용해 SQL script로 테스트에 필요한 데이터를 구축하였습니다.

@Sql 어노테이션은 메서드 실행 전 스크립트를 실행시켜 테스트 간의 격리를 보장해줄 수 있습니다.

덕분에 @Transcation 및 @AfterAll 등 추가적인 작업은 해주지 않아도 됐습니다.

columnDefinition H2 Create 문에서 에러가 발생했는데, 해당 포스팅 참고 부탁드립니다.

[스프링+코틀린] H2 Create Table 문 에러

추가로, SQL문 마지막에 세미콜론이 없으면 에러가 발생하는 내용도 포함되어 있습니다.

2. 조회 테스트 필요 유무

두 번째 고민했던 부분은 조회 테스트가 필요 유무입니다.

단위 테스트 책에서는 조회에 대한 테스트는 불필요하다했고, 예외 상황(ex BadRequestException)만 테스트해도 괜찮다고 명시되어 있습니다.

3. repository 테스트 필요 유무

이 역시 복잡한 조회 테스트를 제외하고는 불필요하다고 합니다.

추가로, 제 생각은 JpaRepository에서 제공하는 기본 메서드는 이미 검증되었다 판단하고 테스트는 불필요하다고 생각합니다.

결론

저도 예전에는 repository 및 조회 테스트를 mocking해서 테스트를 진행했었습니다.

그렇게 하면 제가 mocking한 부분만 테스트를 할 수 있고, 놓칠 수 있는 부분이 생길 수 있습니다.

이러한 테스트 방법도 한 번 시도해보는 것도 좋아보입니다.