테스트 코드

나는 테스트 코드 작성까지가 개발의 완성이라고 생각한다. 개발의 시작을 테스트라고 보는 TDD를 주장하는 사람은 아니다. (테스트 코드를 작성하지 않는 한국의 개발 문화 탓인지 놀라울 정도로 자주, 단순히 테스트 코드를 작성하는 것이 TDD라고 생각하는 사람들이 있는데 맞는 구석 하나 없이 단단히 틀린 생각이다.) 테스트 코드가 있고 없고는 작성한 코드가 의도한 대로 동작하는지, 추가적인 변경사항이 기존의 동작을 망가트리지는 않는지, 이전에 발생한 버그가 다시 발생하지는 않는지, 구조를 바꾸었을 때 생기는 문제가 없지는 않은지 등에 있어 정확히 0과 1만큼의 차이가 난다. 이미 구닥다리가 된 표현이지만 self-documenting하다는 점에서도 기존 코드 이해에 훌륭한 도움이 된다.

애석하게도 나는 이 의견에 동의하는 팀을 만나보지 못했다. 나름대로의 열과 성을 다해 전도도 해보고, 부분적으로 성공한 적도 있긴 한데, 기본적으로는 그렇다. 묵묵히 나의 테스트 코드를 쓰려 하지만 조직에 테스트 코드를 쓰는 문화가 없다면 혼자서는 아무리 써도 의미가 크게 퇴색되는 것이 사실이다. 테스트 문화가 없는 조직에서는 CI/CD에서 테스트 코드가 돌지 않기 때문에 의미가 반감되고, 전체 스위트를 돌리면 적개는 수 개월에서 길게는 연 단위로 유지보수되지 않은 케이스들이 우수수 실패하기 때문에 나머지 절반의 의미가 사라진다.

원인은 다양하다. 시간이 없어서. 익숙하지 않아서. 몰라서. 중요하지 않아서. 테스트 코드가 없다면 작성한 코드가 의도한 대로 동작하는지는 수동으로 파악해야 하고, 문제가 터진 다음에야 어디서 문제가 생겼는지를 추적해야 한다. 테스트를 쓴다고 모든 문제에 bulletproof가 되는 것도 아니고, 최근 들어서는 나도 문제를 방지하는 것보다 또는 그만큼이나 문제가 발생했을 때 신속하게 파악하고 해결하는 것이 중요하다고 믿게 되었지만, 테스트 코드는 무슨 대단히 실력 있는 개발자가 무지막지한 여유가 있어서 하는 일이 아니다. 테스트 코드 없이라면 수동으로, 힘들게, 복잡하고 어렵게 해야 하는 일을 기계가 대신 하도록 해주는 일일 뿐이다. 그리고 개발자의 일은 길고 귀찮고 복잡한 문제를 기계가 대신하도록 만드는 것이다.