[Jpa] 테스트는 어느 부분까지 해야할까?

 

웹 서비스를 만드는데 항상 CRUD를 접한다. 기존 레거시 코드에서는 DAO 를 직접 작성을 해서 테스트는 진행하지만 안정성을 보장해 줄 수 없다.

 

하지만 Spring data JPA 를 사용하여 우리는 CRUD를 정말 편하게 작성할 수 있다.

 

Spring이 Bean으로 등록된 객체들을 관리하여 DI 를 직접 해주고 아주 편리해졌다.

 

오늘은 이 부분에 대해 테스트를 어디까지 진행해야 할 까? 라는 주제를 정해 글을 써보겠습니다.

 

 

DAO 테스트 작성은 간단하다 하지만 귀찮다!

DAO를 작성하여 직접 사용하시는 분은 CRUD를 가지고 테스트 하시는 일은 매우 간단한 일이다.

 

테스트도 매우 간단하게 할 것이다. 저장이라는 행위를 테스트 한다고 가정해보면 해당 엔티티 데이터를 생성하여 데이터베이스에 접근하고 데이터를 저장하고 저장된 데이터를 가져와서 검증을 진행할 것이다.

 

많은 도메인을 테스트하려면 간단하지만 아주 귀찮은??(귀찮아지면 안돼~~~~~~) 테스트 코드를 작성해야 한다.

 

Jpa를 사용하면 기본적인 CRUD를 사용하기에 데이터베이스에 커넥션하는 코드를 작성하지 않고 해당 인터페이스의 메서드를 사용하기에 편해졌다. 하지만 이 역시도 테스트를 진행해야 하는 귀찮음이 있다.

 

 

 

위의 테스트 코드처럼 memberRepository를 mocking 하여 반환을 설정해주고 서비스 메서드를 실행하여 테스트를 하는 코드를 각각의 도메인마다 진행해야 한다.

 

…….. 한숨만 나옵니다.

 

 

 

Jpa의 기본적인 CRUD는 믿고 지나가자!

대부분의 서비스 기업에서 Spring Data Jpa를 사용하는데 기본적인 CRUD는 테스트를 진행 하지 않는다고 한다.

 

위의 내용처럼 각 도메인마다 같은 패턴의 테스트를 진행하기에 시간 소비가 있고 이미 잘 만들어진 라이브러리이기 때문에 믿고 지나간다고 한다.

 

하지만 비지니스 로직, 예외 발생 로직 등등 은 테스트를 필히 해야 한다.

 

위의 테스트 코드를 리팩터링 하여 다시 테스트 해보자.

 

 

먼저 회원정보를 저장하는데 회원 정보가 중복이 되는지 체크를 해야 한다.

 

회원 정보가 중복이 되면 예외가 발생하고 발생된 예외의 검증을 하고 실제로 예외 발생시에 save() 메서드가 호출이 되지 않는지 검증 한다.

 

 

 

 

결론

기본적인 CRUD는 Jpa에 믿고 지나가고 비지니스 로직을 테스트하는 것이 서비스를 안정화 하기에 좋다.

그리고 시간이 절약되며 다른 코드들을 보며 리팩터링을 할 수 있는 시간을 가질 수 있다.!!!

 

 

 

 

 

짧은 글이지만 이 글에 문제가 있다면 피드백 해주시면 감사드리겠습니다.!