스프링 테스트 코드 전환기 시작 (2/3): 테스트 코드를 어떤 방향으로 짤까

구글에서 말하는 테스트

책이 워낙 방대하니 책에서 말하는 테스트가 필요한 이유를 요약하겠습니다. 요점은 시스템이 확장하는데 테스트가 없다면 수정이 자유롭지 못하게 된다는 것입니다. 테스트 코드가 없다면 이 코드가 어디까지 영향을 줄지 예측할 수 없기 때문에, 개발자들은 코드 한번 수정하는데 소극적이게 됩니다. 그 결과 구글도 2000년대에 구글 웹서버를 확장하기 위해 수 많은 인력을 투입했으나 개발 속도에 진전이 없었다고합니다. 그리고 버그도 크게 줄어들지 않았다고 합니다. 개인적으로 올해 시스템이 커지면서 업무 상에 실수가 많았다고 생각하는데, 상황이 상황이었던지라 이런 대목을 읽으니 크게 공감하였습니다.

 

구글에서 정의한 테스트의 세 분류

구글에서 정의한 테스트는 크게 3가지로 분류할 수 있습니다. 소형 테스트, 중형 테스트, 대형 테스트입니다. 

 

소형 테스트

소형 테스트에서 가장 중요한 제약은 단일 프로세스에서 돌아간다는 것입니다. 더 나아가면 단일 스레드에서 돌아갈 수 있어야 합니다. 이는 즉 테스트를 실행하는 같은 프로세스에서, 테스트가 돌아가야 한다는 의미입니다. 테스트를 하면서 서버를 실행시켜서는 안되고, 별도의 테스트 프로세스를 서버에 연결해서도 안됩니다. 즉 DB와 같은 서드 파티 프로그램을 실행시켜선 안된다는 의미이기도 합니다. 그리고 sleep이나 I/O 동작 같은 blocking call 을 사용해서는 안됩니다. 이러한 조건들이 붙은 이유는 간단합니다. 이러한 조건들 덕분에 소형 테스트는 결정적이게 됩니다. 즉 언제 돌려도 항상 같은 결과를 낸다는 겁니다. 소형 테스트는 단위 테스트와 혼용해서 사용되기도 합니다.

 

중형 테스트

중형 테스트는 여러 프로세스와 스레드를 사용할 수 있고, 로컬 호스트에 있는 네트워크 호출을 포함한 blocking call 도 허용합니다.하지만 테스트가 로컬 호스트 외의 다른 시스템과 통신하는 것을 허용하지 않습니다. 다른 말로, 테스트는 반드시 단일 머신 안에서 해결되어야 합니다.

 

대형 테스트

대형 테스트는 중형 테스트가 갖고 있던 로컬 호스트 제약이 없어집니다. 테스트가 여러 머신들과 통신하는 것을 허용합니다. end-to-end 테스트가 여기에 해당합니다.

 

이상적인 테스트 비율

이렇게 테스트를 분류하고나면 소프트웨어에 테스트를 작성할 때 비율 같은 것을 작성할 수 있을겁니다. 어떤 비율을 갖고 있는게 좋을까요? 자연스럽게도 아래와 같은 형태가 제일 좋다고 합니다. 소형 테스트가 많고 그다음이 중형, 대형 테스트는 제일 조금 가지고 있는 형태입니다.

이와 반대로 몇가지 안티 패턴들이 있는테 소형 테스트가 부족하고 대형 테스트가 많은 경우를 아이스크림 패턴, 소형, 대형 테스트만 많고 중형 테스트가 없는 경우를 모래시계 패턴이라고 부릅니다.

일단 여기까지 읽고 하나의 인사이트를 얻었습니다. 결국 현재의 프로젝트에 필요한 것은 api 엔드포인트를 찔러서 확인해보는 end-to-end 테스트가 아니었습니다. MSA 사이에 복잡하게 얽힌 로직의 테스트도 아니었습니다. 단위 테스트였습니다.