단위 테스트(Unit Test) 실천 소감 Q & A

  단위 테스트에 대해서는 오래전부터 익히 들어서 알고 있었고, 관련 프레임워크도 구해놓았건만 선뜻 적용하지 못하고 있었습니다. 그러다가 이번에 진행중인 개인적인 프로젝트에서야 본격적으로 단위 테스트를 도입하게 됐습니다.

  지금까지 단위 테스트의 도입을 망설이게 된 이유는 몇 가지 있었습니다. 일단 프로젝트가 한참 진행 중에 끼워 넣게 되면 어디를 어떻게 테스트해야 할 지가 막막해 진다는 것, 그리고 중복된 코드가 발생한다는 문제입니다. 그리고 혼자서 개발할 수 있을 정도의 소규모의 작업에서는 별로 필요성을 못 느낀 탓도 있습니다.

  하지만, 제가 단위 테스트를 딱 하루동안 적용해보고 내린 결론은 이겁니다.

ⓒ 土塚理弘・五十嵐あぐり / スクウェアエニックス・バンブーブレードパー

이것은 좋은 것입니다.

  한마디로 단위 테스트를 도입한 덕분에 버그를 예전보다 훨씬 빨리, 게다가 많이 발견할 수 있었고, 디버깅 하기도 굉장히 편했습니다. 책으로만 읽어서 알고 있던 단위 테스트의 효과가 바로 눈에 띄게 드러나더군요. 이렇게 단위 테스트를 도입한 이후, 저의 느낌과 생각들을 간단히 Q & A(라 쓰고 '자문자답'이라 읽습니다) 형식으로 간단히 정리해 보았습니다.


  Q1. 단위 테스트의 가장 큰 효과는?
  A1. 문제를 빨리 발견할 수 있습니다.

  당연한 말이겠지만, 버그는 최대한 빠른 시점에 발견 되는 것이 좋습니다. 런타임 보다는 컴파일 타임에 발견되는 오류가 더 고치기 쉬운 것과도 마찬가지 입니다. 버그가 발견되는 가장 좋은 시점이라고 하면 '버그가 막 발생하기 시작한 시기'라고 할 수 있겠습니다. 그러면 어떤 이유 때문에 문제가 발생되는지 쉽게 추측할 수 있으니까요.

  단위 테스트는 무언가의 변경이 일어났을 때, 그것이 일으킬 문제를 빨리 캐치해 낼 수 있는 장치입니다. 물론 이는 테스트를 얼마나 꼼꼼하게 작성하느냐에 달린 문제이기도 하지만, 최소한 단위 테스트 항목에 적혀있는 범위 내에서 뭔가 문제가 일어난다면 바로 알 수 있습니다. 단, 무언가에 변경이 가해졌을 때 마다 자주 테스트를 돌려서 확인해 주는 습관도 필요합니다.


  Q2. 그냥 테스트 팀에서 꼼꼼하게 체크해 주면 안되나?
  A2. 버그 리포트를 기다리기 보다, 일찌감치 버그를 발견하는 편이 덜 고생합니다.

  같은 맥락입니다. 버그가 늦게 발견될 수록 프로그래머의 고생 지수는 급상승합니다. 보잉사에서 항공기를 제작할 때 역시 '빨리 실패하기' 방법을 썼습니다. 단위 테스트는 개발하는 방향이 지금 바르게(의도했던 대로) 가고 있는지 아닌지를 알려주는 일종의 신호등입니다.

  그리고 단위 테스트는 순수하게 프로그래머의 작업을 위한 코딩 단계에서의 테스트입니다. 프로그래머가 자신이 의도한 대로 코드가 동작하고 있는지에 대한 테스트이기 때문에, 이런 테스트는 프로그래머가 직접 만들지 않으면 의미가 없습니다.


  Q3. 단위 테스트를 도입하면 테스터는 필요없나?
  A3. 그래도 필요합니다.

  예초에 단위 테스트는 프로그래머의 작업을 위한, 프로그래머의 관점에서 하는 테스트입니다. 이것은 사용성 테스트와는 별개의 것입니다. 말하자면 단위 테스트만 가지고 모든 종류의 테스트를 대체할 수는 없습니다. 그러니까 테스트 팀에게도 아직 할일은 많이 남아 있다는 거죠. 특히 UI에 관계된 부분은 단위 테스트로 처리하기가 어려운 점이 있습니다.

  대신, 단위 테스트 과정에서 시시콜콜한 버그들은 대부분 걸러질 것이기 때문에 테스트 팀에서는 보다 양질의(?) 버그를 찾으려 할 겁니다.


  Q4. 단위 테스트 작성은 코드의 중복이지 않나?
  A4. 그래도 해야 합니다.

  확실히 중복이 발생합니다. 중복이 해로운 이유란 결국 하나에 변경이 가해지면 나머지 것들도 싸그리 바꿔줘야 하는 삽질이 필요하기 때문입니다. 하지만, 반대로 생각해 보세요. 코드가 변경되었습니다. 그래서 이 때문에 테스트 해야 될 내용도 바뀌게 되었다면 당연히 테스트용 코드도 변경해야 하죠. 결국 단위 테스트를 도입하는 순간, 코드와 테스트는 같이 가야할 운명인 겁니다. 이렇게 중복을 끌어안으면서까지 단위 테스트를 도입해야 되는 건, 그런 중복의 부작용을 충분히 뛰어넘을 만큼의 가치가 있기 때문입니다.

  그리고 단위 테스트를 도입했을 경우에는 한번에 많은 변경을 가하지 말고, 조금씩 변경하고 테스트도 조금씩 고쳐나가면서 자주 테스트를 돌려서 확인하는 방식으로 작업하는 게 좋다고 봅니다. 이런 방식으로 작업하면 테스트를 고쳐나가는 데 있어서 그리 부담이 걸리지 않습니다.

  그리고 테스트 내용이 한번에 많이 변경되어야 한다면 그 설계는 뭔가 잘못되었다는 신호일 가능성이 큽니다. 테스트 전체를 뒤집어야 될 정도의 상황이라면, 그만큼 실제 코드도 뒤집어야 한다는 건데, 그러면 차라리 처음부터 새로 작성하는 편이 낫겠죠?

  그리고 익숙해지면 테스트 코드 역시 최소한의 중복으로 작성할 수 있게 될 겁니다.


  Q5. 솔직히 매번 테스트 작성하는거 귀찮지 않나?
  A5. 그래도 해야 합니다.

  네, 솔직히 귀찮습니다. 하지만 단위 테스트를 일종의 보험이라고 생각할 수 있습니다. 뻔히 잘 동작하는 코드라는 것을 알고도 관련 테스트는 빠짐없이 해야 합니다. 지금은 잘 동작해도 나중에는 어떨지 모르기 때문입니다.

  귀찮음을 무릅쓰고 테스트를 꼼꼼하게 작성해 놓으면, 나중에 좀 더 적극적으로 코드를 변경할 수 있게 됩니다. 왜냐면 지금 작성한 코드가 최소한 단위 테스트를 통과할 정도의 안정성이 있다는 것이 증명되어 있기 때문입니다. 그리고 변경을 가해서 발생되는 문제 역시 테스트를 돌려보면 바로 드러나기 때문이죠.

  한번 제대로 만든 테스트 코드는 두고 두고 써먹습니다.