1 분 소요

보통은 구현을 할때 정상적인 시나리오로 동작할 수 있도록 코드를 구현하고, 그뒤 테스트를 하곤 합니다.

제품을 실행시켜보고, if()문이 정상적으로 동작해서 올바른 값을 출력하는지 확인하죠. 때로는 문서화된 테스트 명세서 없이도 말입니다. 꼼꼼하신 분들은 else 도 잘 동작하는지 확인하시죠.

사실 구현 개발을 하는 것만도 시간이 빠듯한데, 테스트 명세서까지 작성하려면 참 힘듭니다.

조직에 따라서 테스트와 테스트 명세서 작성을 전담하는 인원이 있는 곳도 있겠지만, 사실 이렇게 풍요로운 곳이 있다면… 부럽습니다. 혹은 테스트 명세서 작성을 위해 계속 소통하느라 많은 시간을 할애할 수도 있으니깐, 무턱대고 부러워할 필요는 없을 수도 있고요.

시간이 지나 다양한 코드 구현이 추가되고 프로젝트가 점점 커지면, 테스트 명세의 일부만 가볍게 테스트되고(혹은 그냥 무시되고), else문의 테스트는 고사하고 if()문도 테스트가 안되는 경우가 많아지게 됩니다.

생각지도 못한 디버깅 업무도 많아지고, 요구사항 수정도 점점 많아지기에, 코드 수정으로 인한 테스트 명세서의 수정은 점점 뒷전으로 밀리고, 테스트 명세의 최신화는 점점 어려워 집니다.

호기롭게 시작한 테스트 명세서는 이제 추억의 문서가 되버리죠. 어디다 저장했는지 기억도 안나고요.

기능 구현이나 디버깅 후 사이드 이펙트가 있는지 검증할때, 제대로된 테스트 명세서가 없어서 기억에 의존해 테스트 하다 보면, 한계에 부딪힙니다. 테스트 되지 않은 어떤 곳에 무슨 문제가 발생할까요? 불안감을 떨쳐 버릴 수 없죠.

코드에서 악취가 나서 리팩토링 하려고 해도, 테스트 명세서가 최신이 아니니 또다시 기억에 의존해 테스트 하며 리팩토링 할 수 밖에 없습니다. 그러나 이러한 리팩토링은 사이드 이펙트만 줄줄이 나오는 대규모 민폐가 될 확률이 높습니다. 무서워서 리팩토링 못하죠. 썩은 코드는 금새 백만 라인이 되고, 시장에서 매장됩니다.

이걸 한방에 해결하는게 테스트 주도 개발(Test-Driven Development, TDD) 입니다.

우선 자동화된 단위 테스트 프레임워크를 구축하고,

  1. 테스트를 먼저 작성후 실패하고(빨강)
  2. 테스트를 가까스로 통과시킨 뒤(초록)
  3. 코드 중복이 없도록 코드를 간결하게 정리(리팩토링)

의 순서로 구현하는 겁니다.

그러면,

  1. 테스트 명세서를 작성할 필요가 없습니다.
  2. 테스트 명세서가 코드에서 최신의 상태로 유지됩니다.
  3. 자동화된 단위 테스트기로 회귀 테스트를 수행하여 사이드 이펙트를 순식간에 검출할 수 있습니다.
  4. 리팩토링이 성공했는지 검증할 수 있습니다.

다음과 같은 좋은 효과도 나타납니다.

  1. 테스트되지 않는 코드는 없습니다.
  2. 테스트 만들기 귀찮아서 언젠간 유용할 것 같지만, 영원히 사용 안하는 쓸데없는 코드를 작성하지 않습니다.
  3. 테스트를 먼저 빠르게 작성하다보니, 구현 코드의 함수 호출이나 사용법이 간결하고 직관적으로 작성됩니다.
  4. 리팩토링이 무섭지 않습니다.

한마디로,

작동하는 깔끔한 코드(Clean Code That Works)

만 만들게 됩니다.

단지, 구현하고 테스트하는 순서만 바뀔 뿐인데, 마법처럼 코드의 질과 삶의 질이 달라집니다.

잊지마세요!!!

  1. 프로젝트 시작시에 자동화된 단위 테스트 프레임워크를 구축합니다.(테스트 자동화 참고)

  2. 그리고 오로지 !!!빨강-초록-리팩토링!!!(테스트 주도 개발 참고)

댓글남기기