클린 코드를 위한 테스트 주도 개발 4장

기존에 본인이 개발을 하면서 지켜왔던 TDD라는 개념이 한 기업과의 기술면접에서 틀리다는 것을 알게 되었고 다시 한번 TDD의 개념을 재정립 하기 위하여 본 내용을 작성합니다.

파이썬을 이용한 클린 코드를 위한 테스트 주도 개발

본 책의 내용을 정리하며 TDD가 무엇인지 다시 한번 고민해봅니다.

프로그래밍은 정말 어려운 작업이다. 종종 똑똑한 사람들이 성공하는 경우가 있다.

TDD는 똑똑하지 못한 우리들을 도와주기 위해 존재한다. 켄트 벡(TDD를 고안한 사람)은 우물가에 있는 물 뜨는 두레박을 비유로 들어 설명한다. 우물이 깊지 않으면 두레박도 꽉 차지 않아서 퍼 올리는 것이 쉽다. 가득 차 있다고 해도 처음 몇 번은 쉽게 할 수 있다. 하지만 시간이 지나면서 곧 지치기 시작한다. 하지만 이 때 도르래를 이용하면 직접 퍼 올리는 것 보다 효율적이다.

TDD는 이런 도르래와 같아서 여러분의 작업 효율을 올려주고 쉴 시간도 준다.

아마 대부분은 TDD가 좋은 방법이라는 것을 인정할 준비가 되어 있겠지만 여전히 '이 정도까지 할 필요가 있나?' 하는 의문을 품은 사람도 있을 것이다. 작은 것도 테스트 해야 하고, 터무니 없이 많은 작은 단계들을 거쳐야 하는 것 일까?

TDD는 훈련이다. 즉 자연스럽게 익힐 수 있는 것이 아니다. 대부분의 성과가 즉시 보여지는 것이 아니라, 오랜 기간을 거쳐야 보기이 때문에 여러분 자신이 TDD에 적응할 수 있도록 노력을 해야 한다.

시시한 함수에 대한 시시한 테스트의 이점

단기적 관점에선 간단한 함수나 상수를 위한 테스트 작성이 하찮게 여겨질 수 있다. 물론 보다 수월한 규칙(일부만 단위 테스트를 하는)을 따라서 TDD를 적당하게 할 수 있다. 하지만 이 책을 통해 필자가 보여주고자 하는 것은 완벽하면서도 철저한 TDD이다.

이것은 무술의 카타와 같다 (즉 정확한 동작을 배워서 기술 자체가 여러분의 뇌 근육이 되도록 하는 것이다. 문제는 애플리케이션이 복잡해지면서 발생하게 되는데, 이 때는 정말 테스트가 필요해진다. 하지만 복잡성이라는 것은 여러분들이 모르는 사이에 조금씩 다가와서 복잡하다는 것 자체를 인지하지 못하고 얼마 되지 않아 끓는 물 속에 개구리 꼴이 되는 것이다.)

간단한 함수를 위한 간단한 테스트에 대해 언급하고 싶은 두 가지가 있다.

첫 번째는 테스트가 정말 시시한 테스트라면 테스트 작성 자체에 시간이 많이 걸리지 않는다는 것 이다. 그러니 불평말고 작성하도록 하자

두 번째는 틀을 사용하는 것이 도움이 된다는 것이다. 쉬운 함수를 위한 테스트 틀이 있다면 함수가 복잡해지더라도 심리적 부담을 줄일 수 있다. (단기간에 if 제어나 for 루프 처리가 늘어날 수 있다.) 여러분이 인지하기도 전에 프로그램이 다형성 트리 파서 구조가 되더니 어느새 재귀 처리로까지 번질 수 있다. 하지만 초반부터 틀을 갖추어 테스트를 했기 떄문에 새로운 테스트를 추가하는 것이 자연스럽고 테스트도 수월하다. 테스트를 해야 할 정도로 복잡하다고 판단한 후 테스트를 작성하기 시작한다면 틀이 없기 때문에 훨씬 많은 수고를 들여서 테스트를 만들고 수정해야 한다.

TDD가 훌륭한 이유 중 하나가 다음에 무엇을 해야 할지 잊어버릴 걱정이 없다는 것이다. 테스트를 다시 실행하기만 하면 다음 작업이 무엇인지 가르쳐준다.

리팩토링에 관해

리팩토링 시에는 앱 코드와 테스트 코드를 한 번에 수정하는 것이 아니라 하나씩 수정해야 한다.

리팩토링 시에는 몇 가지 처리를 수정하기 위해 단계를 건너뛰는 경향이 있다. 하지만 반 이상의 파일을 수정하기 시작하면서 자신이 무엇을 수정했는지 모르게 되고 결국 아무것도 동작하지 않게 된다. 리팩토링 캣 처럼 되고 싶지 않다면 작은 단계로 나누어 착실히 작업하도록 하자.