김영한 스프링 입문 6. 스프링 DB 접근 기술 - 스프링 통합 테스트

인프런 김영한 스프링 입문

섹션 6. 스프링 DB 접근 기술

- 스프링 통합 테스트

 

Test도 실제 DB까지 연결하여 동작하는 통합 테스트를 할 예정.

 

이전에 했던 테스트들은 스프링과 관련이 없고, 순수 자바 코드만을 가지고 했었음.

현재는 순수 자바 코드만으로는 테스트를 할 수 없음 -> DB 커넥션 정보도 스프링 부트가 가지고 있기 때문에.

-> 테스트를 Spring 과 엮어서 해볼 것임.

 

현재 'MemberServiceTest'는 Java JVM안에서 끝남.   

 

1. 'MemberServiceTest' 파일을 복사하여 같은 위치에 'MemberServiceIntegrationTest'라는 파일명으로 붙여넣기.

 

2. MemoryMemberRepository를 memberRepository로 수정하고, memberService와 memberRepository 앞에 @Autowired annotation추가

@Autowired MemberService memberService;
@Autowired MemberRepository memberRepository;

이전에는 직접 MemoryMemberRepository, MemberService 객체를 생성해서 넣었음, 이제는 Spring Container에게 해당 객체들을 받아옴.

+ 기존 코드들은 생성자 injection이 좋으나, test 코드는 간단하게 field injection으로 받아도 됨.

이렇게 하면 구현체는 'SpringConfig' 한 곳에서 올라온다.

 

 

3. 기존 코드의 '@BeforeEach', '@AfterEach' 및 사용하지 않는 코드 모두 삭제

-> @AfterEach가 필요 없는 이유는 맨 위에 추가한 @Transactional 때문, 추후 설명 예정

현재 코드 상태 : 

package hello.hellospring.service;

import hello.hellospring.domain.Member;
import hello.hellospring.repository.MemberRepository;
import hello.hellospring.repository.MemoryMemberRepository;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.transaction.annotation.Transactional;

import static org.assertj.core.api.Assertions.assertThat;
import static org.junit.jupiter.api.Assertions.assertThrows;

@SpringBootTest
@Transactional
class MemberServiceIntegrationTest {

    @Autowired MemberService memberService;
    @Autowired MemberRepository memberRepository;


    @Test
    void 회원가입() {
        //given
        Member member = new Member();
        member.setName("spring");

        //when
        Long saveId = memberService.join(member);

        //then
        Member findMember = memberService.findOne(saveId).get();
        assertThat(member.getName()).isEqualTo(findMember.getName());
    }

    @Test
    public void 중복_회원_예외(){
        //given
        Member member1 = new Member();
        member1.setName("mem");

        Member member2 = new Member();
        member2.setName("mem");

        //when
        memberService.join(member1);
        IllegalStateException e = assertThrows(IllegalStateException.class, () -> memberService.join(member2));

        assertThat(e.getMessage()).isEqualTo("이미 존재하는 회원입니다");
    }

}

 

 

4. 여기서 '회원가입'에 대한 테스트를 실행 > 다음과 같은 에러 발생.

'java.lang.IllegalStateException: 이미 존재하는 회원입니다'.

-> 왜냐하면 DB에 'spring'이라는 이름의 회원 존재, test 파일에서 'spring'이라는 이름으로 회원가입 했기 때문.

-> DB의 데이터를 완전 지워줘야함.

 

 

5. h2 웹콘솔에 아래 코드 입력 -> 모든 행 지우기

delete from member

 

이후 조회해보면 아래 사진과 같이 모든 데이터가 삭제되어있어야 함.

실제 DB에 값이 추가되기 때문에 이 상태로 test 돌려야함.

(보통은 test용 DB가 별개로 존재함.)

 

6. 다시 회원가입 메소드 test 실행

아까와는 다르게 위 사진과 같이 test인데 spring이 뜸.

 

7. @Transactional annotation을 주석처리하고 다시 회원가입() test를 돌려보자.

 

처음 실행할 땐 잘 돌아가고, DB에도 'spring'이 잘 올라와 있다.

 

 

8. 그러나 다시 한번 또 돌리면 에러가 뜬다.

 

Test는 반복해서 실행할 수 있어야한다.

이때 Spring이 좋은(기가막힌) 기능을 제공한다.

DB는 기본적으로 'Transaction'이라는 개념이 있음.

그래서 디비에 데이터를 insert query 한 다음에 commit이라는 것을 해줘야 디비에 반영이 됨.

혹은 auto commit 이라는게 존재해서, 보통 auto commit이냐 아니냐의 차이이고, 기본적으로는 transaction이라는 개념이 있어서 다 insert 쿼리를 한 뒤에 commit을 하기 전까지는 DB에 반영이 되지 않음.

auto commit은 커밋이 자동으로 되는 것.

 

그런데 테스트가 끝난 뒤 롤백을 하면 디비에서 데이터가 모두 없어짐, 반영이 안됨.

이렇게 검증을 할 수 있는 방법이 바로 '@Transactional'이라는 annotation.

이걸 test case에 달면, 테스트를 실행할 때 transaction을 먼저 실행한 뒤, db에 insert query로 데이터를 넣은 다음에

테스트가 끝나면 롤백을 해줌.

그래서 디비에 넣었던 데이터가 깔끔하게 반영이 안되고 다 지워짐.

 

 

9. 우선 지금 디비에 있는 데이터를 지워준다

delete from member;

 

 

10. 7에서 주석처리한 @Transactional 어노테이션을 다시 주석처리하지 않고 회원가입 테스트를 실행한다.

그러면 몇번을 실행해도 테스트가 실행된 뒤에 디비를 봐도 깔끔!

 

테스트를 시작하기 전에 transaction을 걸고,

db에 쿼리를 다 날린다. (그래서 findOne, join 등등 다 됨)

그 후 테스트가 끝날 때 롤백 해버림(반영을 아예 하지 않음)

 

-> DB의 실제 데이터에 반영이 되어있지 않음 

-> 다음 테스트를 반복해서 실행할 수 있다!

기존처럼 지우는 코드를 넣지 않아도 됨.

 

 

11. 18번 라인 왼쪽을 클릭해 전체 test파일 실행

중복 회원 예외 및 회원가입 모두 정상적으로 실행!

 

 

정리

- @SpringBootTest : 스프링 컨테이너와 테스트를 함께 실행함.

- @Transactional : 테스트 케이스에 이 애노테이션이 있으면, 테스트 시작 전에 트랜잭션을 시작하고, 테스트 완료 후에 항상 롤백한다. 이렇게 하면 DB에 데이터가 남지 않으므로 다음 테스트에 영향을 주지 않는다. (테스트케이스에 붙었을 때만 이런식으로 작동한다)

 

단위 테스트 : 순수하게 자바 코드로 하면서 최소한의 단위로 하는 테스트

통합 테스트 : 디비, 스프링컨테이너까지 연동한 테스트

 

이때 순수한 단위 테스트가 훨씬 좋은 테스트일 확률이 높음.

그러므로 순수한 단위, 단위로 쪼개서 테스트를 잘 할 수 있도록 하고, 스프링 컨테이너 없이 테스트할 수 있도록 훈련해야함.

꼭 그런건 아니지만, 그럴 확률이 높다.

어쩔수 없이 컨테이너까지 올려야하는 상황이라면, 테스트 설계가 잘못 됐을 확률이 높음.

통합 테스트도 필요하긴 하나, 단위 테스트를 잘 만드는 것이 좋음!!!

 

 

다음 시간에는 스프링의 JDBC 템플릿으로 바꿔서 돌려볼 것임!