TDD 0부: 들어가며
Test-Drive Development (TDD), 테스트 주도 개발
이 책에 관하여
원서의 제목은 Test-Driven Development: By Example 이고 번역서 제목은 테스트 주도 개발이다. By Example이라는 부제가 빠져있다. 부제는 두 가지로 해석 가능하다. 첫째로, 이 책 자체가 TDD를 설명할 때 예를 들어가며 설명한다는 뜻이고, 둘째로 TDD는 그 자체가 예를 통해서 진행된다는 뜻이기도 하다. (TDD에서 테스트는 유용하고 문제 해결에 본질적인 시스템 사용의 예로 구성됨) 특히 예에 의한 사고와 프로그래밍이 정말 강력하며, TDD에 있어 예의 역할이 중요하여 후자의 의미를 되뇌어야 한다.
테스트 주도 개발은 하나의 기술이지만 그 이면에는 사고의 근원적 변화가 있다. 데밍은 품질에 대한 책임을 그 누구보다도 작업자에게 맡겨야 한다고 주장한다. 이는 제조업 세계에서 효과가 있었는데, 인간적이기도 하지만 작업자가 정보를 제일 많이 알고 있고, 또 최종 결과에 직접적 영향을 가장 많이 끼칠 수 있기 때문이다. 수십년이 지난 소프트웨어 개발 커뮤니티는 동일한 과정을 밟고 있다. 프로그래머가 자기 작업의 품질에 대한 우선적 책임을 져야한다. TDD를 실천법으로 적용하는 것은 도움이 될 수 있지만, 책임을 맡는 방법으로 사용하면 더욱 강력해 질 것이다.
흔히들 TDD를 하면 모든 과정은 컴퓨터 화면 속에서만 벌어진다고 생각하기 쉽다. 하지만 그보다 중요한 곳이 바로 개발자들, 우리의 머릿속이다. 올바른 길이 있고 자신이 그 길을 따라가지 못한다고 느끼면 자책과 자기 비하가 일어난다. 그러나 이런 생각을 하는 순간부터 화면 위에서의 승부는 더 곤두박질치게 된다. 하지만, 자신의 내면에서 벌어지는 일에 관심을 갖고 심리적 안정 상태를 유지하면 엄청난 차이를 경험할 수 있게 된다. 테스트를 돌리고 예상과 달리 실패하면, 어디에서 왜 이런 오류가 났을까 생각하며 소스 코드를 보지 않고 머릿속에서 이미지를 짐작해본다. 그리고나서 실제 코드를 살피며 생각한 대로 코드를 고쳐보며 TDD를 진행한다. 빨리 테스트를 통과시키려고, 혹은 프로그램을 빨리 작성하려고 너무 조바심 내지 마십시오. TDD를 쫓아가려고 하지 말고 TDD가 자신을 따라오게 해야 한다.
TDD의 특성상 완성된 프로그램 코드를 보거나, 간단한 매뉴얼 정도로는 TDD를 익힐 수 없다. 그 과정을 하나하나 따라가야 한다. 특히나 TDD를 체화할 때는 건너뛸 수 없는 게 있는 것 같다. 공력을 쌓는 것은 속성이 어렵고 또 남의 동작을 보고 관찰하는 것만으로 자기화할 수 없다. 분명 자기 수련이 필요하다. 이후에 나오는 TDD 수련법을 따르거나 스스로 단순한 규칙을 정해놓고 지키기 위해 노력하면서 자기만의 노하우를 구축해야 한다. 이와 동시에 실무에서 조금씩 작용 범위를 넓혀가야 한다. 분명 엄청나게 좌절할 것이다. 하지만 그 좌절을 하나 둘 넘어서면서 시야가 점점 넓어져 갈 것이다.
TDD 수련법
테스트 주도 개발을 잘하려면, 훈련과 경험이 필요하다. 책에서는 처음 훈련은 다음 방법 수을 권한다.
- 간단하고 쉬운 문제들을 TDD로 시도한다. 가능하면 전에 접하고, 프로그래밍 해본 문제가 좋다.
- 초록 막대 주기는 가능하면 짧도록 한다.
- 이때 초록 막대 주기의 최대 시간을 정해놓고 진행하다가 시간을 초과하면 직전 초록 막대 상태로 돌린 다음 새로 시작하는 것이 좋다.
- '진짜로 만들기 전까지만 가짜로 구현하기' 를 적극적으로 사용하려 노력한다.
- 초기에는 리팩토링 툴을 사용하지 않는 것이 좋다. 순서와 과정을 익히기 위함이다.
이어서, 파에 해당하는 방법을 시도한다.
- 여유를 가져야 한다. TDD가 꼭 정신없이, 별 생각없이 프로그래밍을 하는 것은 아니다.모든 '학습' 과 '개선' 의 필수적 요소는 자기를 돌아보기와 자기가 생각하는 것을 생각하는 메타인식이다. 자신이 하는 것을 관조, 관찰, 기록, 분석하는 편이 좋다.
- 잘 된다 싶으면 속도를 높이고 뭔가 안 풀린다 싶으면 바로 속도를 늦추는, 보폭을 조절해본다.
이 단계를 넘어서면 리 훈련을 해볼 수 있다.
- TDD를 사용하지 않고 같은 문제에 접근해보자. TDD를 써서 좋을 때가 있고 안 써서 좋을 때가 있나 살펴본다.
- TDD와 적절한 초기 설계를 섞어보자. 어떤 '좋은 부분' 이 남는지, 어느 정도가 적절한 수준인지 감을 잡자.
- TDD와 함께 다른 방법들을 시도해보자.
의도에 의한 프로그래밍,단계적 개선,도메인 주도 설계등.
위 방법들은 하나 하나를 오랜 기간을 두고 수련해볼 만 하다. 그리고 배움의 과정을 수파리 세 단계로 나눠놓기는 했지만, 하나의 방편일 뿐이지 실제로는 이런 구분이 모호하며 무의미하다.
저자의 당부
론 제프리즈의 '작동하는 깔끔한 코드' 가 바로 테스트 주도 개발의 궁극적인 목표다. TDD는 예측 가능한 개발 방법으로 끊임없이 발생할 버그에 대해 걱정하지 않고, 일이 언제 마무리될지 알 수 있다. TDD에서는 아래의 두 가지 단순한 규칙만을 따른다.
- 오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다.
- 중복을 제거한다.
이 규칙에 의해 프로그래밍 순서가 다음과 같이 결정된다.
빨강- 실패하는 작은 테스트를 작성한다. 처음에는 컴파일조차 되지 않을 수 있다.초록- 빨리 테스트가 통과하게끔 만든다. 이를 위해 어떤 죄악을 저질러도 좋다.리팩토링- 일단 테스트를 통과하게만 하는 와중에 생겨난 모든 중복을 제거한다.
이처럼 개발자가 테스트를 만드는 추가 작업을 하면서까지 이 방식을 채택해야 하는 이유는 바로 두려움을 극복할 수 있는 용기 때문이다. 여기서 두려움이란 '정말 어려운 문제라서 시작 단계인 지금은 어떻게 마무리될지 알 수 없군.' 하는 식의 합리적인 두려움을 말한다. 이런 두려움은 다음과 가은 일의 원인을 제공하기도 한다.
- 두려움은 행동의 실천을 망설이게 만든다.
- 두려움은 다른 이들과의 소통을 덜 하게 만든다.
- 두려움은 스스로를 까다롭게 만든다.
이 중 어떠한 것도 프로그래밍에 도움이 되지 않는다. 따라서,
- 불확실한 상태로 있는 대신, 가능하면 재빨리 구체적인 학습을 하기 시작한다.
- 침묵을 지키는 대신, 좀 더 분명하게 커뮤니케이션한다.
- 피드백을 회피하는 대신, 도움이 되고 구체적인 피드백을 찾는다.
테스트 주도 개발의 테스트는 톱니바퀴의 이빨과 같다. 이랃ㄴ 테스트 하나를 작동하게 하면, 그게 지금 현재 그리고 앞으로 영원히 작동할 거라는 걸 알 수 있다. 테스트가 망가져 있을 때에 비해, 모든 것이 작동하는 쪽으로 한 걸음 더 가까이 다가갈 수 있다.
TDD란 프로그래밍 도중 내린 결정과 그 결정에 대한 피드백 사이의 간격을 인지하고, 또한 이 간격을 통제할 수 있게 해주는 기술을 말한다. 이 책을 읽고 나면
- 단순하게 시작하고
- 자동화된 테스트를 만들고
- 새로운 설계 결정을 한 번에 하나씩 도입하기 위해 리팩토링을 할 준비가 될 것이다.
