TDD 오해 - 1

TDD 하는 사람들은 모든 기능을 구현할 때 TDD를(만) 이용해서 구현한다.

많은 분이 이야기하듯 모든 기능에 TDD를 사용할 필요는 없습니다. 물론 가능은 하겠지만, 시간이나 에너지의 낭비가 될 수 있습니다. 예를 들어 데이터베이스에 저장이 잘 되는지 HTTP 호출은 잘 되는지 등 굳이 테스트하지 않아도 되는 부분이 존재하기 마련입니다. 혹은 HTML에서 내가 그리게 될 요소가 잘 그려지는지, 어느 위치에 그려지는지 등은 꼭 TDD를 통해 작성하지 않아도 직접 테스트해 결과를 확인할 수 있고 피드백도 빠르게 받을 수 있습니다.

TDD는 내가 구현해야 하는 기능 중 논리에 관한 영역과 내가 생각한 설계를 시험해보고 그 결과를 빠르게 피드백 받는 방법이라고 생각합니다. 따라서 모든 것의 시작을 테스트로 잡지 않아도 충분히 TDD를 한다고 할 수 있습니다(이는 두 번째 오해로 이어짐).

덧붙여, 테스트가 모두 코드를 통해 수행된다는 강박을 가지지 않아도 될 것 같습니다.

TDD 오해 - 2

TDD는 테스트를 먼저 작성해야만 TDD!

회사에서 우연히 동료와 TDD에 관한 이야길 나누는데 동료는 TDD의 제1 정의(젤 먼저 말 해서?;;)를 테스트를 먼저 작성한다.라고 생각하고 있었습니다. 시작부터 테스트 작성의 선후를 이야기해서 즉시 피드백을 줬습니다.

제 생각에 테스트가 먼저냐 아니냐는 TDD에서 가장 중요한 가치도, 꼭 논해야 하는 명제도 아니라고 생각합니다. 우리가 최종적으로 보게 될 코드는 일종의 스냅샷으로 테스트를 먼저 작성했는지 하지 않았는지 알 수 있는 방법이 잘(거의?) 없습니다. 물론 그 과정은 상당히 중요합니다.

테스트를 작성하면서 실패하는 동시에 문제점을 피드백 받고 성공하는 동시에 다음 작업을 생각할 신호를 뇌에 입력받게 되는 일련의 흐름이라고 볼 수 있습니다. 그리고 성공한 테스트들은 우리에게 안정감을 줍니다. 익숙하다면 테스트를 작성하는 과정에서 지루함도 얻을 수 있습니다. 하루하루 똥줄 타고 마음이 심숭생숭한 코드를 배치하느니 지루함과 안정감을 얻는 쪽을 택하는 편이 여가를 알차게 보낼 수 있는 방법이 아닐까 합니다.

그리고 테스트 먼저란 말에서 먼저의 기준은 무엇입니까? 무엇보다 먼저 해야 테스트를 먼저 작성하는 건가요? 운영 코드?

TDD by example이란 책을 보면 마치 테스트 코드를 먼저 작성하는 듯한, 그리고 테스트 코드를 먼저 작성하는 흐름을 읽을 수 있는데, 이는 아주 커다란 착각(내가 착각 하는 건가…?)입니다. 여기까지 읽고 TDD by example에서도 “테스트를 먼저 작성하라"는 말이 있는데 무슨 헛소리냐고 하시는 분들이 있다면 다시 한번 책 내용을 떠올려 보시는 건 어떨까요? (저는 기억이 잘 안 나지만 다시 읽진 않…)

제가 읽은 내용을 떠올려보면, 책에서 무엇보다 가장 먼저 한 건 생각입니다. 즉 무슨 일(해야 할 일)을 어떻게 해야 할지 미리 생각해보고 이를 통해 어떤 코드를 작성할지 예측해 봤던 거죠. 그리고 난 후에야 테스트 코드를 작성하고 비로소 실패하는 피드백을 받기 시작합니다(말 장난 인가…?).

위 내용을 통해 짐작해 보면 역시 TDD는 설계를 테스트하는 방법이다.라는 말이 와닿기 시작합니다. 테스트 코드를 통해 최대한 작은 코드를 유지하고 원하는 기능은 모두 갖추는 등 좋은 점이 많이 있습니다. 다만, TDD를 한다고 해서 반드시 좋은 설계를 갖는 것은 아닙니다. 예를 들어, 테스트할 주요 대상 외 필요한 개체들을 모의(Mock)로 작성해 테스트 코드를 작성한다면 불필요한 추상화 등이 이뤄질 수 있습니다. 이는 적당히 경계하면서 진행해야 할 요소입니다.

잡담

현재 저는 TypeScript라는 구전으로만 들어오던 언어를 사용해 화면을 구성해보고 있습니다. TDD를 사용해 작성하려 하고 있고, 원하는 기능은 테스트를 통한 피드백을 받고 천천히 개발하고 있습니다. 하지만 문제는 테스트한 코드와 실제 작동의 괴리에서 옵니다. 물론 저도 초보이고 매우 간단한 화면을 구성하고 있기 때문에 큰 문제는 아직 일어나지 않았습니다.

예를 들어, 테스트 코드에선 잘 작동했고 원하는 기능을 잘 수행하는데 실제 프로젝트를 확인해보면 가끔 엉뚱한 결과가 나오는 경우입니다. 잘못된 점을 다시 생각해보면 테스트가 잘못 작성(엄한 테스트 코드를 덕지덕지 작성해두기)되었거나 테스트를 통해 미닫이문을 만들어 놓고 실제로는 문 앞뒤로 벽을 생성해둔 경우같이 코드 배치가 잘못된 느낌의 구성을 한 경우였던 것 같습니다.

끝

TDD를 오랜 시간 해온 분들처럼 글을 쓰거나 읽으면서 틀린 생각을 빠르게 피드백 받아 TDD에 관한 더 깊은 내용과 실제 예제를 들고 다시 찾아올 수 있었으면 좋겠습니다.

그리고 젤 중요한: “항상 목적이 무엇인지 생각하자!”