[TIL] <테스트 주도 개발> 읽기 1

사실 업무에서 테스트 코드를 작성하는 것은 이제 선택이 아닌 필수로 여겨지는 것 같다. 다들 단위 테스트를 작성하고 있고, 많은 사람들이 통합 테스트도 고민하고 있다. 나 역시 일 하면서 테스트를 꼭 작성하고, 커버리지를 높게 가져가기 위해 항상 노력 하고 있다.

그렇다면 왜 <테스트 주도 개발>을 읽어야 하는가? 사실 테스트 코드를 작성하고 있지만, 나 스스로는 항상 아쉬움을 느낀 것 같다. 어느 날 갑자기 회사라는 밀림에 던져져 조직의 컨벤션을 따라가다 보니 테스트 코드를 짜고 있다. 하지만, 테스트 주도 개발을 좀 더 깊게 이해하지 못하고 수박 겉핥기 식으로 하고 있다는 두려움에 종종 빠져들었다. 그래서, 이 책을 꼭 한번 읽고 지나가고 싶었다.

반세기 전, 일본으로 간 데밍과 같은 경영학자들은 품질경영이라는 아이디어를 일본 산업계에 전수했다. 데밍은 품질에 대한 책임은 작업자 본인에게 맡겨야 한다고 봤다. 작업자 스스로가 다른 누구보다 만들고 있는 제품의 품질을 잘 이해하기 때문이었다.

켄트 벡은 ‘50년이 지난 지금 소프트웨어 개발 커뮤니티는 동일한 깨달음에 도달하고 있습니다. 프로그래머가 자기 작업의 품질에 대한 우선적 책임을 져야 한다는 깨달음이죠.’ 라고 말한다.

<테스트 주도 개발(Test-Driven Development: By Example)>의 시작부에 나오는 이야기다. 이 글을 읽고, 이 책을 반드시 끝까지 읽어내야 겠다는 결심을 했다. 소프트웨어 엔지니어, 그 안에서 코드를 짜고 있는 개발자, 혹은 프로그래머는 자신이 작성한 코드에 무한 책임을 져야 한다고 생각한다. 코드의 퀄리티와 작동할 것이라는 신뢰를 위해 충분한 노력을 기울여야할 의무가 있다고 생각한다. 그렇기 때문에 어쩌면 테스트 코드를 짜는 것은 당연하다. 코드의 품질과 작동하는 기능의 품질에 대한 확신을 갖기 위해, 테스트 주도 개발 방법론을 채택하는 것 또한 고려해볼 만 하다고 생각했다.

2가지 원칙

  • 오직 자동화된 테스트가 실패할 경우에만 새 코드를 작성한다
  • (리팩토링을 통해) 중복을 제거한다.

위 2가지 원칙이 테스트 주도 개발의 전부라고 한다.

보다 자세히 정리하면 이렇다.

  1. 실패하는 작은 테스트를 만든다. 당연히 코드 없이 테스트 코드만 있다면 그 테스트는 실패한다.
  2. 테스트 코드를 통과하기 위해 코드의 퀄리티를 신경쓰지 않고 어떻게든 기능을 구현한다.
  3. 리팩토링을 한다. 통과하는 코드 내의 중복을 제거하고 코드를 개선한다.

테스트의 목적은 용기

코드를 짜는 일은 가끔 두렵다. 내가 짠 코드가 실 서비스로 배포된 뒤 심각한 장애에 빠지는 것은 정말 두려운 일이다. 회사를 다니다 보면 종종 그런 위기를 경험하거나, 다른 사람이 그런 위기에 빠지는 것을 목격하게 된다. 잘못된 코드를 배포해 회사의 매출에 타격이 생기거나, 긴 시간 서비스가 장애로 이용불가 상태에 빠진다.

이런 악몽은 아마 거의 모든 개발자들이 가장 두려워하는 시나리오일 것이다. 그래서 우리는 테스트를 작성한다. 테스트코드 만이 이러한 악몽에서 우리를 보호할 가장 확실한 방패이기 때문이다.

일단 테스트를 하나 작동하게 하면, 우리는 발판 하나를 얻은 셈이다. 그 발판을 딛고 또 하나의 테스트를 작성하고 통과시키며 점차 발판을 쌓아나가면 된다. 어쩌면 이것이 복잡한 소프트웨어라는 거대한 괴물 리바이어던(레비아탄)과 싸워내는 가장 확실한 방법인지도 모른다.

한계

물론 몇가지 한계도 있다고 한다. 켄트 벡을 인용하면 여전히 인간의 판단이 개입되어야할 가능성이 큰 보안 소프트웨어나 테스트하기 곤란한 동시성 이슈 들은 TDD를 적용하기 어려울 수 있다고 한다.

물론 나 역시 테스트의 중요성을 인지하지만 TDD가 무조건 옳다고 맹신하려는 것은 아니다. 더 나은 테스트 코드를 작성하는 방법의 일환으로서 TDD 방법론을 참고하고 싶어 이 책을 읽어나가고 있다.

마치며

매일 조금씩 읽어나가며 TIL 형식으로 책의 내용을 정리해 나가려고 한다. TDD 방식으로 간단한 TODO API를 개발해보기도 하면서 스스로 장단점과 한계를 느껴보려고도 한다.