6-3. 스프링 통합 테스트

데이터베이스까지 포함된 테스트를 해보는 회차.

 

테스트를 돌리고 나면 그 테스트를 돌리기 이전으로 DB를 롤백해주는

@Transactional

이라는 어노테이션을 배운다.

 

 

 

 

 

지금까지 만들었던 테스트들은 스프링과 관련 없이 순수 자바 코드로만 만든 것이라고 한다.

테스트를 돌리면 모든 것이 JVM 내에서 이루어진다고 한다.

 

사실 스프링 초보인 나의 눈으로는 코드를 읽고 그런 사실을 알아채기 힘들다. 강사님이 그렇다고 하니 그렇구나 할 뿐이다.

추측을 해보자면, 이제서야 시스템 메모리가 아닌 제대로 된 DB를 사용하기 시작했고, 이 DB에 관한 정보는 내가 쓴 코드가 아니라 스프링이 들고 있다. 이것을 이제부터는 테스트에 반영할 것이라서 이런 말씀을 하셨나 보다.

그리고 '스프링 DB 접근 기술' 챕터의 나머지 강의들을 보니, 거의 마법처럼 느껴질 정도로 "스프링이 다 해줬다" 싶은 요소들이 등장한다. 이것들을 아직까지는 안 사용했고 지금부터 사용할 것이라는 의미의 말씀일 수도 있겠다.

공부할 것이 정말 많다!

 

 

 

 

 

스프링 통합 테스트 코드 짜기

 

아무튼 이제부터는

우리가 새로 마련한 제대로 된 DB를 반영해서 테스트를 만들어야 한다.

 

 

먼저 이렇게 MemberServiceTest를 복사 붙여넣기 한 다음 이름만 MemberServiceIntegrationTest로 바꾸어준다.

같은 구조에서 내용만 바꾸어줄 것이기 때문이다.

 

 

@SpringBootTest와 @Transactional 어노테이션을 붙여준다.

 

 

먼저 여기 필드 선언과 객체 생성 메소드 beforeEach를 손봐준다.

beforeEach는 @BeforeEach를 이용하여 매 테스트메소드 시작 전에 새 객체를 생성해주는 메소드이다.

선언은 남겨두고 beforeEach는 아예 지워버린다.

 

 

이렇게 선언 앞에 @Autowired를 붙이기만 하면 끝이다.

beforeEach는 필요 없다! 왜냐하면 @Transactional 어노테이션 때문에, 이 테스트로 인하여 DB에 생긴 변경사항들은 테스트 종료 후 자동으로 롤백되기 때문이다.

 

 

그리고 또 한 가지 팁이 있다.

정확히 몇 번째 회차였는지는 기억이 안 나지만 이 강의의 전 회차들 중 하나에서,

이렇게 필드 선언 앞에 @Autowired를 붙여서 스프링 빈들의 의존관계를 명시하는 것은

생성자의 앞머리에 @Autowired를 붙이는 방법보다 안 좋다고 배웠다.

 

그러나 테스트 코드는 특수하다.

다른 코드에서 테스트 코드를 참고하여 더 뻗어나가는 일이 없다. 테스트를 돌리기만 하면 이 코드의 역할은 거기서 끝이다.

그러므로 위와 같이 필드에 @Autowired를 붙여서 대충 해주어도 괜찮다고 한다.

 

 

 

 

 

돌려보기

 

이렇게 하면 끝이다!

아래의 테스트 메소드는 하나도 안 건드려도 된다.

 

 

이제 테스트를 돌려본다.

무서우니 join만 일단 돌려본다.

 

실패했다. assert문을 돌렸는데 두 객체의 값이 서로 다르다고 나왔기 때문이다.

아무래도 mem1은 id가 부여되지 않고 이름만 있는 상태이고, joinedId 및 foundMem은 id가 부여된 상태여서 그런 게 아닐까 싶다.

강사님의 코드를 보니 강사님은 Member 객체의 이름 값만 빼와서 비교하고 있다. 나도 그렇게 고쳐야겠다.

 

 

강사님처럼 getName()을 넣어 돌리니 테스트가 pass됐다.

 

 

롤백이 잘 되어서, DB 안의 데이터도 테스트 전과 동일하다.

 

 

duplicatedName도 잘 pass된다.

 

 

 

 

 

 

 

 

@Transactional의 역할

테스트 케이스에 @Transactional 어노테이션이 있으면

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

테스트 완료 후에 항상 그 transaction을 롤백한다!

 

단, 테스트 케이스가 아닌 일반 코드에 붙었을 때는 롤백이 일어나지 않는다.

테스트 케이스에 붙었을 때만! 롤백이 일어난다.

 

이것과 반대로 항상 DB에 커밋이 되도록 하는 어노테이션은 @Commit 이다.

 

 

 

 

 

 

메모리를 사용하는 테스트는 필요 없는가?

그렇다면

우리가 DB를 사용하기 전에 만들어놓은,

DB를 사용하지 않고 또 스프링 없이 자바 코드만으로 작동하는,

PC의 메모리를 사용해서 작동하는 이 테스트는 이제 필요가 없는 것일까?

 

아니다.

우리가 코드의 로직을 잘 짰는지만 순수하게 테스트할 때는 이렇게 스프링 없이 돌아가는 테스트가 훨씬 좋다.

그러므로, 스프링에 기대지 않고도 로직을 테스트할 수 있는 테스트 케이스를 언제나 짜놓도록 해야 한다. 만약 그런 테스트 케이스를 짤 수가 없다고 느껴진다면 내가 잘못하고 있는 것이다. 무조건 만들어보자.

 

그리고 이런 테스트 케이스가 실행에 걸리는 시간도 훨씬 짧다.