TDD로 개발하면 좋을까? (why TDD)

이 포스팅은 개인적, 주관적 해석이 듬뿍 들어가있습니다.

---

TDD(Test-Driven-Development)란?

TDD 창시자 켄트 백이 TDD라는 용어를 만들기 전에 먼저 고려 했던 키워드는 TFP (Test-First-Programming)입니다. 말 그대로 테스트 코드를 먼저 만들고, 실제 프로덕션 코드를 나중에 만드는 개발 방법을 말합니다. 그래서 TDD와 상반되는 개념으로 테스트 코드를 나중에 작성하는 방식을 TLP(Test-Last-Programming) 혹은 TLD(Test-Last-Development)라고 합니다.

 

TDD없이 개발할 때 종종 겪는 개발 시나리오

1. 프로덕션 코드 A 만들기.

2. 코드A의 테스트 코드 작성하기.

   (테스트는 당연히 통과된다. 작성된 프로덕션 코드에 끼어맞춰서 테스트 코드를 만들었기 때문에~!)

3. 위에서 만든 코드 A를 사용하는 프로덕션 코드 B 만들기.

   (하지만 코드A를 사용해보니 무언가 잘못됨을 뒤늦게 깨닫는다.)

   "아, 매개변수로 들어가서 고려되어야 하는 값이 하나 더 있었군.."

4. 다시 프로덕션 코드 A를 수정한다. 빼먹은 매개변수를 집어넣는다.

5. 다시 코드A의 테스트 코드를 작성한다. (테스트는 당연히 통과된다.)

6. 위에서 수정한 코드A를 사용하는 코드B를 만들기.

   (하지만 여기서 무언가 잘못됨을 또 깨닫는다.)

   "아, 반환타입을 이게 아니라 다른 걸로 받는게 좋겠군.."

7. ....(반복)

"도대체 테스트 코드는 하는 일이 뭐야? 아니면 애초에 설계를 완벽하게 하지 못한 잘못인가?"

 

왜 TDD로 개발 해야 하는가? (why TDD)

TDD를 처음 접할 때는 매우 혼란스럽습니다. 존재하지도 않는 메소드 (혹은 객체)를 사용하면서 컴파일 에러 경고를 잔뜩 뱉어내는 IDE를 보고 있자면, 그 순간은 무언가 잘못된 코드를 만드는건 아닌지 고통스러운 순간을 지켜봐야 합니다.

 

하지만 존재하지도 않는 코드를 사용한다는 것은 그 코드를 사용하는 사용자의 입장이 되는 것을 말합니다. 코드가 어떤식으로 올바르게 동작해야하는 지를 정확하게 아는 사람은 그 코드를 만드는 '개발자'가 아니라 그 코드를 사용하는 '사용자'입니다. (사용자는 다른 사람이 아니라 그 코드를 사용하는 미래의 '자신'이 될 수 도 있습니다.)

 

정리하자면 코드(메소드나 객체)의 존재 목적은 '만들어 지는 것'이 아니라 '사용되는 것'입니다.

 

테스트를 먼저 작성한다면 코드가 '올바르게 사용되는 방식'을 사전에 알 수 있고, 이러한 접근만으로도 더 나은 프로덕션 코드를 작성 할 수 있습니다.

 

창시자 켄트백이 말하는 진짜 가치는?

켄트 백이 테스트 주도 개발을 설명하면서 강조하는 진짜 가치는 '어려운 일을 작은 단계로 쪼갤 수 있는 능력' 입니다. 어렵고 난해한 요구사항을 아주 작고 쉬운 일로 쪼개어서 한걸음씩 진행을 하는 능력이 있다면 언젠간 정복 할 수 있습니다. 켄트 백은 작은 단계의 전진을 할 때 '먼저 작성된 테스트'가 올바른 길잡이가 되어 준다고 말합니다.

 

간혹 TDD의 장점을 설명 할 때 마치 테스트코드의 장점을 TDD만이 누리고 있는 것처럼 말하는 사람들도 있습니다. 하지만 올바른 테스트 코드가 존재한다면, 그게 먼저 작성되었건 나중에 작성 되었건 그것은 테스트의 장점이지 TDD만의 장점이 아닙니다. 그리고 켄트 백이 말하는 TDD의 가치는 테스트코드에 있지 않습니다.

 

'테스트 주도 개발' 책 전반에 걸쳐서 '어려운 일을 작은 단계로 쪼갤 수 있는 능력'을 강조하고 있고 이 능력을 갖추기 위해서 테스트라는 방식을 사용 했을 뿐입니다. 만약에 어려운 일을 작은 단계로 쪼갤 수 있는 더 좋은 방식이 있다면 켄트백은 테스트라는 방식을 버리고 그 방식을 선택할 것이라고 확신합니다. 다만 켄트백이 제시하는 TDD 사이클을 잘 지키고 실천하는 것만으로도 이러한 가치를 누릴 수 있기 때문에 많은 개발자들이 TDD를 애용하고 있습니다. (이는 주관적 해석임을 다시 한번 밝히며 마무리 하겠습니다.)

 

 

(+ 20.11.21 TDD를 실천하면서 느껴본 장점들)

• TDD 싸이클은 3단계로 테스트케이스 작성 -> 프로덕션코드 작성 -> 리팩토링이다. 이러한 싸이클 단계를 진행하면서 얻을 수 있는 명확한 장점은 한가지 일에만 집중할 수 있다는 것이다. 처음부터 테스트하기 용이하고, 기능의 구현이 되며, 읽기 좋은 코드로 만들고자 한다면 한번에 3가지를 신경써야만 한다. TDD싸이클 단계는분리해서 생각하게 도와준다. 
• 1단계 : 테스트 케이스를 먼저 작성하며 코드의 사용자 입장에서 코드를 작성해보고, 코드 형태가 테스트 용이한 형태로 만들어진다. 테스트 용이한 형태로 만들려면 필연적으로 모듈은 한가지 일을 명확하게 하고 분명하게 쪼개진다.
• 2단계 : 프로덕션 코드를 빠르게 만들어 볼 수 있다. 처음부터 완벽한 변수명, 최적화된 성능, 예쁘게 읽기 좋은 코드를 생각하지 않아도 좋다. 2단계에서는 모든 면죄부가 주어진다. 일단 돌아가게 만들면 된다.
• 3단계 : 리팩토링이라고 대단한 개념을 생각하지 않아도 된다. 2단계에서 저지른 악행들을 만회하는 단계다. 변수명을 예쁘게 바꿔보고, 가독성을 생각하며, 가독성을 해치지 않는 범위에서 성능도 생각해볼 수 있는 여유가 생긴다. 

---

참고자료

테스트 주도 개발 (인사이트) - 저자 : 켄트 백