시작하며

현 회사에서 기존에 개발되어 운영 중인 서비스를 담당하게 되었다.
처음엔 단순 유지보수만 하면 될 줄 알았지만 시간이 지날수록 기존 코드를 수정하고 새로운 기능을 추가해야 하는 일이 잦아졌다.

이런 과정에서 가장 큰 고민은 코드 수정이나 기능 추가 후 기존 기능들이 정상 작동 하는것이냐였다.
물론 문제 없이 잘 돌아가면 좋겠지만, 현실은 그렇지 않았다.
수정 후 직접 확인했음에도 예상치 못한 곳에서 에러가 튀어나오곤 해서 결국 모든 기능을 일일이 확인해야만 했다.

시간이 충분하다면 전부 꼼꼼히 확인하는 게 최선이겠지만, 현실적으로 매번 그러기는 힘들다.

이런 고민을 하다 문득 취준생 시절 기술 면접에서 자주 들었던 질문이 떠올랐다.
"테스트 코드 작성해보셨어요?"
아이러니하게도 취업 후엔 테스트 코드를 작성할 기회가 줄어들어 그 중요성을 잊고 있었다.
이번 경험을 계기로 테스트 코드의 필요성을 다시 한번 느끼고, 제대로 공부해보기로 마음먹었다.

TDD란

TDD(TEST-DRIVEN DEVELOPMENT)는 동작하는 코드를 작성하기 이전에, 테스트를 먼저 작성하고, 그 테스트를 통과하는 코드를 작성한다. 통과한다면 그 코드를 리팩토링한다.

위의 사진처럼 TDD는 3가지 단계를 한 사이클로 돈다.
1. Write a failing test : 실패하는 작은 테스트 작성. 컴파일러조차 되지 않을 수 있지만 일단 작성한다.
2. Make the test pass : 테스트를 통과하도록 최소한의 코딩을 하는 것
3. Refactor : 리팩토링. 중복된 코드를 제거하는 등 코드를 리팩토링한다.

왜 실패하는 작은 테스트를 작성해야하는 것일까?

내 생각에는 테스트 코드를 써보고 실행해서 잘못되었을 경우, 더 개발이 진행되기 전에 개발 초기 단계에서 잘못된 코드/분석 및 설계라는 것을 깨달을 수 있기 때문이라 생각한다.

테스트 코드를 작성하다보면, 코드의 구조에 대해서 깊게 고민할 수 있고, 새로운 방향을 깨달을 수 있다.
더더욱 복잡한 로직일수록 체계적으로 해결해 더 옳은 방향으로 개발 할 수 있도록 깨달을 수 있기 때문이다.

초기 프로젝트에 대해서 분석하고 설계하는 것은 생각보다 굉장히 어려운 일이라고 생각한다.
프로젝트의 미래와 방향 등은 모두 "추측"에 기반되어 시작된다.

이런 추측에 기반해 오랜 기간 설계하고 구현하다보면 해당 설계가 맞으면 좋겠지만, 선택한 설계 방향이 적절하지 않음을 깨달을 수 있다.

이미 상당 시간을 분석과 설계 그리고 어느정도의 개발 단계까지 투자했기 때문에, 다시 원점으로 되돌리게 된다면 데드라인을 맞추지 못할 가능성이 크다.

반드시 TDD를 사용해야할까?

반드시 필요하다 말하기도 어렵다.
이 글을 쓰기 전까지 나는 오히려 'TDD는 비효율적이다.' 라고 생각하는 개발자 중 한 명이었다.

예를들어, 내가 맡았던 프로젝트들의 경우 개발 기한이 생각보다 굉장히 짧을 때가 많았다.
개인적으로 나는 이해 관계자들과 함께 업무를 진행해야하는 환경 속에서 가장 중요한 것은 무엇보다도 "기한 지키기" 였다.

따라서 기능을 하나 추가할때마다, 테스트 코드를 미리 작성해야하기 때문에 오히려 개발 속도를 늦출 수 있기 때문에 단기적인 생산성을 저하시킬 수 있다고 생각한다.
따라서 대부분의 프로젝트는 "분석 -> 설계 -> 구현 -> 테스트 -> 오픈" 방향으로 개발을 했다.

어느것이 옳고 틀린지 아직은 명확하게 알 수 없으나, 개인적인 생각으론 각 프로젝트마다 환경과 요구사항이 다 다르기 때문에, 상황에 맞는 방법론을 선택하여 테스트하는 것이 좋다고 생각한다.

간단한 예제를 통해서 테스트해보자. (with React.js)