유닛 테스트의 진짜 효과와 역할

유닛 테스트를 내가 접한 지도 어언 10년이 다 되간다.

그간 내가 거쳐온 많은 회사에서 사용되기도, 무시되기도, 우선 순위에 밀리기도 하더라.

 

이 과정에서 제안도 여러 번 해보고, 설득 과정에서 자주 나왔던 질문이 있었다.

 

유닛 테스트하면 뭐가 좋은가요?

 

처음 이 질문을 받았을 당시, 내 답변은

 

테스트야 하면 당연히 좋은 거다

 

라고 답변했었다.

 

사실 누구나 테스트의 중요성은 배운다. 그래서 아주 작은 팀이고 여력이 부족하다면, 개발팀 내 테스트라도 소화하려고들 하는 것은 사실이긴 하다.

 

하지만 많은 사람들에게 테스트란 재미없고, 지루하지만 해야만 하는 교리 같은 것에 불과하다는 것이 문제다.

듣는 사람도 고개는 끄덕였지만, 막상 실천으로 이끌어 들이는 데에는 실패했다.

결과적으로 동기부여에 실패했다.

 

 

이어진 내 고민은, 과연 유닛 테스트의 장점이라고 주장해야, 테스트 검증 개발 (TDD is dead - http://likelink.co.kr/29242 - 이후, 나는 이 생각을 더 굳게 굳혔다. Test Verify Development. 즉 테스트를 통해 검증을 하며 이뤄지는 개발을 말한다)에 동조 할 수 있게 만들 수 있을지 였다.

 

이 과정에서 유닛 테스트 및 시스템 테스트 코드에 대해 여러 가지 대화를 나누곤 했다.

그 과정에서, 그리고 내가 직접 겪었던 테스트 코드의 가장 큰 장점은, 바로 작업자의 의도를 테스트로 강제한다는 점이다.

 

건즈2 팀에서 일 할 당시, 테스트가 깨지는 것은 build가 깨지는 것으로 간주됐다. 왜냐하면 테스트 프로젝트는 각 프로젝트와 대응되어 함께 build 되었으며, post build 이벤트로 테스트가 수행되는 것이 프로세스였는데, 이 과정에 strict한 검사가 많으면 많을 수록, 새로 작성한 코드나 수정된 코드가 기존 작업자의 의도를 벗어난다는 것을 알 수 있었다.

 

그렇다. 유닛 테스트를 통해, 동작하는 코드만으로 부족한 작업자의 의도를 전달하고, 그 의도가 지켜질 수 있었다.

 

이 이야기를 해보면, 유닛 테스트를 팀 프로젝트에 밀접해 적용해온 팀들의 개발자 분들은 비슷한 의견을 내비치셨다.

 

여기서 또 중요한 점이 있다.

 

바로 자신의 코드가, 자신이 의도한 대로 동작하는지를 더 먼저 확인해준다는 점이다.

 

나는 DHH가 위에서 언급한 TDD is dead라는 글을 쓰기 전에도 이미, TDD는 하지 않고 있었다. 난 Post Test Development를 해왔다고 볼 수 있다.

 

그렇게 해오다 보니, 테스트를 작성하는 과정에서 내가 작성한 코드가 의도대로 동작하는지 확인하는 과정을, 그리고 예외 상황에 대한 고민을 테스트 작성하는 과정에서 진행했다.

 

물론 이 과정이 너무 늦어, 설계를 변경해야 되면 어떻게 할거냐는 질문을 받기도 했는데, 사실 설계가 테스트를 통과하지 못해 무너지게끔 구성되어 있다면, 유연하지 못한 코드를 작성한 거라고 봐도 무방하다고 생각한다.

 

사실 아무리 commit message를 잘 작성해도, 문서를 잘 작성해도, 주석을 잘 달아놓아도, build가 깨지는 것만큼 강한 메시지는 없다.

 

그것도 논리적 모호함이 가장 적은 그 언어의 문법에 맞춰 작성된 코드라면 더 할 나위 없이 명확하다.

 

그래서 우리는 유닛 테스트를, 시스템 테스트를 진행 해야만 한다.