[테스트 코드 작성기 1] 간단한 통합 테스트 작성

회사에서 스터디를 하면서 단위 테스트(http://www.yes24.com/Product/Goods/104084175) 책을 읽고 좀 더 빨리 이 책을 읽었다면 정말 좋았겠다 생각이 계속 들었습니다. 

단위 테스트 - YES24

책 내용이 정말 좋은데 테스트 코드 작성에 고민 또는 관심이 있는 분이라면 꼭 한 번 읽어보기를 추천드립니다.

 

책 내용 중 

필요 없거나 또는 나쁜 테스트를 작성하는 것보다는 작성하지 않는 것이 낫다

라는 내용이 있습니다.

 

첫번째 회사에서 테스트 코드가 없어서 프로젝트 진행에 어려움을 겪었던 사람으로서 새로운 회사에서는 어떻게든지 테스트 코드를 많이 작성하고 싶었습니다.

 

하지만 위 책을 읽으면서 정말 가치있는 테스트만 작성하고 유지를 해나가도록 노력해야겠다는 생각이 들어 정말 확신이 들기전까지는 작성하는 것을 미루었습니다.

 

그래서 새로운 회사 입사한지 2달만에 처음으로 간단한 통합 테스트를 작성했습니다.

작성 배경

신규 프로젝트에 들어가서 업무를 하고 있기 때문에 이제 프로젝트의 코드를 막 작성해나가고 있는 상황입니다.

 

5명이 각자 기능을 맡아서 구현을 하게 되는데 배포 시마다 다른 사람이 만든 기능이 깨지지는 않을까에 대한 걱정과 불필요한 커뮤니케이션이 발생했습니다.

 

개발 초기 단계이기 때문에 깨져도 큰 문제가 발생하지는 않지만 각 API를 배포 전 실행되는 간단한(작성 공수가 크지 않은) 통합 테스트가 있으면 좀 더 효율적으로 작업을 해나갈 수 있을 것 같았습니다.

 

그래서 각 API 마다 요청을 날리고 우선은 (적은 노력을 위해) 200 응답 정도만 확인하는 테스트 코드를 작성하였고, 응답값을 세부적으로 확인해야 하는 것은 각 기능 개발을 맡은 개발자가 필요시에 하도록 했습니다.

 

작성 시에는 아래 3가지를 유의했습니다.

1. @SpringBootTest와 @MockMVC를 사용했습니다.

@SpringBootTest는 모든 의존성을 다 올립니다. 이번 통합 테스트의 초점은 회귀방지에 있었기 때문에 목으로 처리하는 것보다는 최대한 많은 코드가 실제로 실행이 되어야 했습니다. 그래서  @SpringBootTest를 사용했고 굳이 실제 servlet container가 올라갈 필요까지는 없었기 때문에 가볍게 @MockMVC으로 처리했습니다. 

 

참고로 @SpringBootTest의 기본 컨테이너 세팅이 Mock입니다.

2. 컨트롤러마다 파일을 나누어 테스트 코드를 작성했습니다.

당연히 파일을 나누어 테스트 코드를 작성하는 것이 좋지 않느냐라고 하지만, 테스트 코드 실행 시에 모든 리소스를 메모리에 올리는 @SpringBootTest를 사용하기 때문에 한 파일에 관련 테스트를 작성해야 하는가 했습니다.

 

여러 파일에 나누어 여러번 @SpringBootTest을 사용되면 테스트 속도가 느려지지 않을까 싶었기 떄문입니다.

 

하지만 다행히도 테스트 프레임워크에서 관련 리소스 캐싱을 제공하고 있었고 여러개의 @SpringBootTest가 있어도 각각 필요 리소스를 올리는 것이 아니라 리소스를 캐싱해 두번째 @SpringBootTest부터는 빠르게 실행되는 것을 볼 수 있었습니다.

3. 가장 긴(관련해서 의존성을 사용하는) 케이스를 고려하여 테스트 파라미터를 추가하였습니다.

통합 테스트 시에는 주요 흐름(가장 긴 흐름)과 도메인 영역 테스트에서 잡지 못하는 예외만 테스트하는 것이 좋습니다.

가장 긴 흐름은 가장 많은 코드와 의존성을 실행시키기 때문에 더 짧은 흐름을 테스트하는 것에 비해 회귀 방지가 높습니다.

 

이를 위해 API 파라미터, 바디에 가장 긴 흐름을 실행할 수 있는 값이 사용되도록 테스트 코드를 작성하였습니다.

 

다음에 또 테스트 코드 작성 후 내용 공유하도록 하겠습니다:)