서론
본 포스팅은 아래의 인강을 듣고, 추가 공부가 필요한 내용들을 포함하여 정리한 포스팅입니다.
Practical Testing: 실용적인 테스트 가이드 - 인프런 | 강의
이 강의를 통해 실무에서 개발하는 방식 그대로, 깔끔하고 명료한 테스트 코드를 작성할 수 있게 됩니다. 테스트 코드가 왜 필요한지, 좋은 테스트 코드란 무엇인지 궁금하신 모든 분을 위한 강
www.inflearn.com
인강을 쭉 따라가다보니 어느새 Business Layer Test를 진행중이다.
해당 테스트에는, 주문을 생성하는 두 개의 테스트 메서드가 있고. 각각 red, green, refactor 과정을 거쳐 테스트를 수행했다.
하지만 위 사진처럼, 두 메서드를 통합하여 테스트 할 경우 테스트 에러가 발생하게 되었고 강의에서는 아래의 코드를 작성하여 해결하였다.
@AfterEach
void tearDown() {
//데이터 클랜징 작업을 통해
//tearDown절에서 clean작업
}@AfterEach 애너테이션이 있는 tearDown 메서드를 활용하여 map의 key가 중복되는 것을 repository의 deleteAll(), deleteAllInBatch()를 사용하여 제거하였는데, 이에 대한 공부를 좀 해볼까 한다.
@AfterEach
한 번에 여러 테스트를 실행하면, 메모리 DB에 이전 테스트 결과가 남을 수 있다. 서론에서 든 예시에서도, 남아있는 map의 key 때문에 에러가 발생하였다.
@AfterEach를 사용하면 각 테스트가 종료될 때 마다 명시된 메서드의 코드들을 실행하기 때문에, 애너테이션의 기능을 활용하여 DB에 저장된 데이터를 삭제하여 테스트를 독립성을 보장해주어야 한다.
class OrderServiceTest {
ProductRepository productRepository = new ProductRepository;
@AfterEach
void tearDown() {
productRepository.clearProduct();
}
(...생략...)위 코드에서는, AfterEach를 통해, 테스트를 수행한 후 DB에 저장되어 있는 product들을 지워주었다.
당연하지만, 해당 repository에서 clearProduct 메서드에 대한 명시를 해주어야 한다.
@BeforeEach
반대로 @BeforeEach는 테스트 실행 전 무조건 실행된다.
공통 설정이나 초기화 작업을 수행하여 중복 코드의 제거를 통한 코드의 가독성 향상을 기대할 수 있다.
또한 일관된 테스트 환경을 설정할 수 있다.
class OrderServiceTest {
ProductRepository productRepository;
@BeforeEach
public void setUp() {
productRepository = new ProductRepository;
}
}
번외
@DataJpaTest는 @Transactional이 붙어있어 @AfterEach를 사용하여 초기화를 하지 않아도 자동 롤백되어 테스트가 통과되었다.
또한 후처리를 하기 위한 @AfterEach를 사용하지 않고, @Transactional을 사용해도 롤백이 되기 때문에 테스트가 통과되었다. 롤백 기능에 대한 편리함 때문에 사용하긴 하지만 실제 배포 시 상황을 고려하며 작성해야 할 것이다.
관련 포스팅
테스트 코드를 작성하는 이유 - TestCode (1)
