테스트 코드를 짜야하는 이유

지금은 행복한 주말인 토요일 오후다, 아침 9시부터 모니터에 앉아 미뤄둔 테스트 코드 작성을 시작하고 서비스, 리포지토리단의 테스트를 짜던 도중 어려움이 생겨 6시간째 의자에서 일어나지 못하고 있다.

 

어떤 어려움이라면 그냥 모르겠는것이다.

 

모델단의 테스트 코드는 굳이 스프링의 도움을 받지 않고 JUnit만으로 짤 수 있었기 때문에 매우 쉬웠다.

하지만 서비스나 리포지토리는 인메모리 테스트용 DB나 mock 객체들을 만들어야하는 등 내가 모르는것이 많았다.

우리 회사에서는 테스트 코드를 짜지 않기 때문에 어디서 경험할 일도 없었다.

 

그래서 열심히 찾아봤다, 많은 방법들이 있지만 나는 항상 실무에서 사용되는 Best Practice인 방법을 배우고 싶어하기 때문에 고민이 많았다. 결국엔 이것저것 시도해보다가 대부분 이렇게 하면 너무 낭비인것같다 혹은 분명 이것보다 더 좋은 방법이 있을테니까 더 헤집어 놓지 말고 가만히 내려놓고 더 공부하고 보자는 생각이 들었다.

 

현재 진행하는 프로젝트가 급해서 인프런에서 수강하고 있던 강의들을 잠시 내려놨기 때문에.. 다시 배우고 짜려고 결심을 했다.

하지만 왜 테스트 코드를 짜야하는지는 여러 방법을 시도해보면서 마음에 와닿게 깨닳은것 같다.

 

https://archanwriteup.tistory.com/entry/SpringBoot-Junit을-이용한-RestAPI-테스트-코드-작성

SpringBoot Junit을 이용한 RestAPI 테스트 코드 작성

약 1년전쯤에 내 블로그에 테스트 코드에 관한 글이 처음으로 올라와 있는것을 볼 수 있다. 이때쯤부터 테스트 코드라는것에 대해서 인지하고 있었던것으로 보인다. 지금 들어가서 보면 좀 지워버리고 싶은 그런 글이다.. 너무 무지한 상태로 작성했다.

 

지금까지 1년 동안 상반기에는 영한님 강의를 정주행하고 하반기에는 슬축생 프로젝트를 열심히 개발했다. 그러면서도 동욱님 블로그나 여러 즐겨보는 회사들의 기술블로그는 항상 봤기 때문에 당연히 테스트코드에 관한 내용도 많이 봤다.

 

아마 동욱님 블로그였던것 같은데 NestJS와 Jest가 테스트하기 Spring보다 더 자유도가 높다고 했던 글을 본적이 있는것 같다. (아마?)

그때는 잘 이해가 안되었다, 테스트의 자유도? 코드를 짜는 방법에 따라 테스트의 자유도나 난이도가 좌우되는가?를 고민했었다.

 

테스트 하기 좋은 코드가 곧 잘 짜여진 코드다, 이 말도 정말 여러군데에서 많이 듣던 말이다. 잘 이해가 안되었는데 오늘 이해가 되었다.

 

옳은 예제인지 모르겠지만 현재 시간을 코드 내부에서 LocalDateTime.now()로 가져와서 사용하는 메서드가 있었다.

하지만 테스트 코드를 하려고 보니 시간이 중요한 기준점인데 내부에서 무조건 현재시간을 가져와서 사용하다보니 테스트에 어려움이 있었다. 그래서 기준 시간을 무조건 현재시간이 아닌 파라미터로 받아오도록 수정했고 서비스에서 호출할때 현재시간을 넘겨주도록 수정했다.

 

이렇게 하니 테스트 코드에서 정상 동작과 시간을 기준으로 한 여러 예외처리 테스트를 쉽게 작성할 수 있었고 최하위단인 모델은 여러곳에서 확장성 있게 사용될 수 있도록 되도록 고정적인 상수를 사용하지 않는 방식이 더 좋은것 같다고 생각이 들었다.

 

이것말고도 예외처리 하는 부분등 여러 부분에서 동작은 문제 없지만 테스트 코드를 작성할때 문제가 되는 부분들이 눈에 보였고 반대로 생각하면 동작을 했으니 문제라고 생각하지 않았을뿐이지 테스트하는 관점으로 보니 좀 올바르지 않은것 같은 메서드들이 눈에 보였다.

 

아직 테스트 코드를 짜는 부분에서는 많이 부족한것 같다, 단순히 구현만 잘하는것이 아닌 테스트 코드도 잘 작성하고 그러기 위해서 여러 설계 아키텍쳐와 디자인 패턴등도 꾸준히 잘 공부해야겠다고 느꼇다.