[Spring boot] 테스트코드의 필요성

이동욱님의 '스프링 부트와 AWS로 혼자 구현하는 웹 서비스' 를 읽으며 새롭게 공부한 내용에 대해 정리합니다.

chap2 에서는

• 단위 테스트의 필요성
• 간단한 테스트코드 작성
• 롬복을 사용하여 DTO 편하게 다루기

등의 내용이 있었다. 그 중 테스트코드의 필요성에 대해 작성하고자 한다.

1. 단위 테스트의 필요성

단위테스트 모습

postman API 요청

 첫 번째 이미지는 단위 테스트코드를 작성하여 진행했던 프로젝트이고, 두 번째 이미지는 테스트코드를 몰랐을 때 전부 API 테스트 도구로 테스트했던 프로젝트이다.

 책에서 단위테스트가 필요한 이유로는 ​빠른 피드백 / 자동검증 / 기존 기능의 정상 동작 보장 을 꼽았다. 이 책을 진작에 읽었어야 하는지, 아니면 겪어보았기 때문에 더 공감이 가는 것인지는 모르겠지만 정말정말 공감가는 내용이었다.

1. 빠른 피드백에 대해

테스트코드 없이 개발을 진행하게 되면, 책에도 쓰여있다시피 다음과 같은 과정을 반복한다.

1. 프로그램 실행
2. Postman 과 같은 API 테스트 도구로 HTTP 요청 후 확인
3. 혹은 요청 결과를 콘솔에 찍어 눈으로 확인
4. 결과가 다르면 서버를 내린 뒤 다시 코드를 수정

 이 과정을 코드가 정상동작할 때까지 반복하게 되는데, 서버를 중지하고, 코드를 수정하고, 다시 실행하는 과정을 반복하다보면 생각보다 정말 많은 시간을 쓰게 된다...ㅋㅋ

 테스트코드를 사용하게 된다면 첫 번째 이미지와 같이 몇 초 안에 우수수 테스트결과를 확인할 수 있다. 이 과정을 반복하여 코드를 수정하면 되기 때문에, 서버를 실행하고...Postman에 적절한 값을 넣어 검증하고...하는 과정을 훨씬 더 빠르게 할 수 있다. (Spring Security 를 사용했다면, 서버를 올릴 때마다 로그인요청을 해서 토큰을 사용해주어야 하는데...사소한 것 하나지만, 이것도 정말 곤혹이다..)

 

2. 자동 검증에 대해 

 테스트코드에 실수가 없다면, 내가 원하는 결과와 테스트 결과가 일치하는지 자동으로 검증이 될 것이다. 그런데 테스트코드가 없다면, API 테스트 도구(Postman)의 Response 를 보며 지금 결과가 잘 넘어온 것인지 사람 눈으로 비교해야 한다.

 이게 별 거 아닌 것 같지만, 나는 Response 에 문제가 없다고 생각하고 코드를 병합했는데, 프론트 쪽에서 어떤 값이 안넘어왔다고 말씀해주실 때도 가끔 있었고, 나도 그런 일이 없도록 하기 위해 수정이 있을 때마다 눈 아프게 Response를 확인하는 것도 은근 큰 노동이었다....테스트결과를 자동 검증해주는 것만 해도 신경 쓸 일이 많이 줄어드는 느낌이다.

 

3. 기존 기능의 정상 동작 보장에 대해

 단위 테스트가 필요한 가장 중요한 이유인 것 같다. 위 두 번째 이미지가 내가 작업했던 API 들인데, 다른 팀원들도 있었기 때문에 다른 도메인에 더 많은 API 들이 있었다.

 xxxService 에서 작성한 메서드를 여러 도메인에서 참조하여 사용하는 경우가 많은데, 메서드를 수정해야 할 때는 당연히 그 메서드를 사용 중인 다른 메서드들도 함께 수정을 해줘야 한다. 이 때, intellij 의 Alt + F7 'find usage' 기능으로 최대한 관련된 코드들을 수정하여 병합했다고 해도, 막상 Postman 으로 테스트를 하면 잘 되던 엉뚱한 곳에서 문제가 발생하기도 한다.

 때문에 코드를 수정하고 나면, 걱정되는 마음에 관련 있을만한 API 를 전부 다 수동으로 확인하곤 했다....(정말 큰 귀찮음이 따른다..) 테스트코드를 작성했다면, 코드를 수정 후 테스트코드만 싹 돌려서 '아 문제가 없구나', '아 여기 문제가 생겼구나' 바로 알 수 있기 때문에 정말정말 편했다.