스프링 테스트 코드 전환기 시작 (1/3): 테스트가 필요하다 느꼈다.

트로이 목마

트로이 목마에 당했습니다. 실제 데스크탑이 트로이 목마 바이러스에 걸렸다는 의미는 아닙니다. 테스트 문화를 전파하는 너무나 강력한 트로이 목마에 걸렸습니다. 올해 초의 일입니다. 회사에 후배님이 신규 입사하셨고, 저희 파트로 배정 받으셨습니다. 저는 후배님에게 현재 작업 중인 프로젝트에대해 설명을 드리며 개발할 내용을 나누었고 코드를 리뷰하고 있었습니다. 그러자 후배님께서 물으셨습니다. "저희는 테스트 코드가 없나요?"

네, 그렇습니다. 부끄럽게도 현재 개발 중인 프로젝트에는 테스트 코드가 거의 없습니다. 변명할 수 있는 이야기는 많지만 적지 않겠습니다.   말그대로 프로젝트 전반에 테스트 코드는 거의 없다고 봐도 무방비합니다. 처음 후배님이 이런 질문을 할 때 여러가지 이유를 들어 이렇게 된 배경에대해 답변드렸습니다. 하지만 그러면서 동시에 테스트 코드를 짜지 않은 것에 양심의 가책을 느꼈습니다.

 

테스트 코드가 없었던 이유

사실 테스트 코드가 거의 없었던 것에는 저의 불찰이 제일 큽니다. 저는 TDD가 이론적으로는 완벽할지 모르지만 현업에서 사용되기에는 무리가 있는 이론이라고 말하고 다녔던 사람입니다. 이런 말을 글로 남기는 것도 조금 조심스럽습니다. TDD는 소프트웨어 개발에서 거의 신성 불가침한 영역이기 때문입니다. [^1]

후배님께 질문을 듣고 혼자 고민을 굉장히 많이 했습니다. 테스트코드를 짜야하나? 어떻게 짜야하지? 프로젝트 특성상 MSA이다 보니 이걸 전부 Mocking 해줘야하는데 이게 맞는건가? 서비스 레이어에 있는 비즈니스 로직은 어떻게 테스트하지? TDD 관련 책도 많이 찾아보고 관련된 세미나 영상도 많이 찾아봤습니다. 하지만 대부분 테스트 코드를 짜는 법, 테스트 코드 관련 라이브러리, 테스트 코드를 통해 얻을 수 있었던 높은 코드 커버리지에대해서만 이야기하고 있었습니다. 딱 입문자의 입맛에 맞을 만큼 간단한 예제만을 다루고 있었으며 그렇게 학습한 내용을 현업에 가져다 쓰기에는 무리가 있었습니다.

 

테스트 코드 전환기의 시작

지금와서 그때 가진 고민을 정리하자면 크게 두가지로 나눌 수 있을 것 같습니다. 첫 번째는 "테스트 코드란 무엇이며 왜 필요하며 어떤 방식으로 작성되어야 하는지를 모르겠다."이고, 또 하나는 "현재 프로젝트에 어떻게 테스트 코드를 작성해야하는지 모르겠다."입니다.

이러한 고민에 해답을 준 것은 얼마 전에 읽었던 구글의 소프트웨어 엔지니어링이라는 책입니다. 이 책을 읽으면서 테스트 코드가 왜 필요한지 설득당했습니다. TDD 관련 책을 읽어도 뭔가 크게 납득이 가질 않았는데, 오히려 소프트웨어 엔지니어링 관련 책을 읽고 설득 당했습니다. 

하지만 해당 책은 코드 레벨의 내용까지는 다루고 있지 않았기 때문에, 읽고 난 다음에도 "그래서 현재 프로젝트를 어떻게 테스트하지?"에 대한 고민에 답을 얻지는 못해 막막했습니다. 그러던 도중 또 하나의 좋은 책을 만납니다. DDD start!라는 책입니다. 두 책 모두 블로그에 정리하기도 했습니다. 정리1, 정리2

구글의 소프트웨어 엔지니어링이라는 책이 테스트 코드가 필요한 이유와 좋은 테스트의 방향성에대해 설명해줬다면, DDD start!는 "아, 이렇게 테스트 코드를 작성하면 되겠구나"하고 영감을 준 책입니다.

 

이러한 배경으로 업무 중인 내용에 테스트 코드를 하나하나 넣어나갈 예정입니다. 그리고 이 포스팅 시리즈는 테스트 코드를 추가하면서 겪는 유의미한 경험담이 있다면 글로 남기려는 시리즈입니다. 그러기 위한 시작으로 현재 프로젝트에 어떤 테스트 코드가 필요하고 어떻게 해결하려하는지를 가볍게 적어보려 합니다.

 

[^1] 변명을 조금 얹자면 혹시 나만 이런가? 라는 생각이들어 회사의 동기들과 굴지의 대기업을 다니는 친구들에게 여기저기 다 물어보고 다녔습니다. 너희 회사는 테스트코드 작성하냐, 작성하면 코드 커버리지는 몇퍼정도 되냐, MSA 환경에서는 테스트를 어떻게하냐 등... 하지만 대부분 테스트 코드를 작성 안하는 것은 매한가지였고 상황도 크게 다르지 않아보였습니다.