테스트 코드의 중요성을 몰랐을까?
당연히 나는 테스트 코드의 중요성은 익히 들어서 알고있었다.
테스트 코드가 있어야 빠르게 회귀 테스트가 가능하니까 리펙토링, 패키지 버전업 등이 훨씬 쉽고 안정성있게 할 수 있다.
새롭게 배포할 때도 테스트 파란불이 들어오면 마음이 한결 놓인다.
예전에 인턴으로 일할 때는 Espresso와 Appium으로 모바일 앱의 E2E 테스트를 작성하는 일이 주 업무였다.
이후로는 테스트 코드를 거의 작성하지 않았는데, 그렇다고 그 경험이 싫어서 피한 건 아니다. 단지 그동안 맡았던 프로젝트들의 성격 때문이었다.
외주, 단발성 프로젝트를 주로 작업했던 입장에서 나는 테스트 코드가 엑스트라 마일이라고 생각했고, 당장의 생산성을 떨어트린다고 생각했다.
스타트업에서 일할 때는 엄청 급격하게 변하는 요구사항과 빠듯한 개발일정에 쫒기다보니 테스트 코드와 멀어졌다.
그러다 부스트캠프에서 다른 사람이 작성한 코드를 리팩토링하는 시간을 갖게 되었고, 기존 테스트 케이스가 아쉬워 보이는 부분을 보완하면서 다시 테스트 코드에 손을 대기 시작했다.
우연히 TDD에도 흥미가 생겨서 새로운 구조와 기능을 만들 때 RED–GREEN–BLUE 과정을 어설프게나마 따라 해보기도 했다.
정말 오랜만에 제대로된 테스트 코드를 작성한 순간이였고, 나는 테스트 코드가 단순히 나에게 안정감을 주는 것 그 이상의 기능을 한다는 것을 몸소 깨달았다.
테스트 코드가 곧 스펙 문서다
전임자가 작성한 테스트 코드를 읽으면서 어떤 의도와 행위를하는 기능들인지 쉽게 이해됐다.
나도 추가 테스트를 작성하면서 describe()와 it()에 최대한 사용자 관점의 설명적 문장을 넣어보니, 이보다 더 명확한 스펙 문서는 없겠다고 생각했다.
그리고 코드가 변화하면서 문서는 구식화되기 쉽지만 테스트 코드는 안바꾸면 실패하니까 구식화되기가 상대적으로 더 어렵다.
코드 퀄리티가 올라간다
이번에 TDD로 처음 개발해보았다. 테스트 케이스당 하나의 기능을 테스트할 수 있도록하는 테스트를 구현에 앞서 먼저 작성했다.
이렇게 작성하다보니 자연스럽게 함수들은 단일 책임 원칙에 따라 쓰여졌다. 함수와 변수의 이름도 더 추상적이고 이해하기 쉽게 쓰여졌다.
구현되지 않은 함수들을 조합해 테스트 코드를 레고처럼 먼저 쌓아 올리다 보니, 설계를 바꾸는 일도 훨씬 수월해졌다. 그리고 테스트 코드가 버티고 있으니까 더 자신 있게, 더 과감하게 리팩토링할 수 있게 됐다.
마치며, 앞으로 시도해볼 것들
구체적인 사례를 자세히 적고 싶지만, 부스트캠프 미션 내용이 혹시나 외부로 유출될까 걱정돼서 그대로 쓰지는 않았다.
많은 개발자분들이 테스트 코드 작성에 AI를 많이 활용하는 것으로 알고있다. 반대로 테스트 코드는 내가 짜고 그걸 바탕으로 AI에게 구현을 시키는 것은 어떨까?
AGENTS.md 같이 AI 에이전트들에게 코드 베이스 설명과 규칙을 적어서 쓰는 것 처럼, 테스트 코드를 스팩 문서로 하여 바이브 코딩을 하면 꽤 괜찮을 것 같다.