[출석 미션] 회고 : TDD를 미워합니다

출석 미션의 부제는 TDD다.

이전에도 여러 번  TDD를 시도해본 적은 많았지만, 이번만큼 철저하게 TDD 사이클을 따르려고 의식적으로 노력했던 적은 없었다.

 

TDD는 직관적이고 이상적인 사이클을 따른다.

• RED: 실패하는 테스트를 먼저 작성한다.
• GREEN: 테스트를 통과할 최소한의 프로덕션 코드를 작성한다.
• REFACTOR: 코드를 리팩토링하여 개선한다.

---

 

먼저 확실히 짚고 넘어가자면, 테스트는 중요하다. 나는 테스트를 사랑한다.

테스트는 리팩토링할 때 자신감을 주고, 프로그램의 신뢰성을 확보하는 핵심 수단이다.
또한 코드의 동작을 명확히 전달하는 문서 역할도 한다.

 

테스트 작성에 최선을 다해야 하는 것은 분명 옳다.

그러나 TDD(Test-Driven Development) 방식에 대해서는 신중한 입장이다.

---

작은 단위에 지나치게 집중할 가능성

TDD 원칙

 

TDD는 작은 단위에 집중하게 만든다. 하나의 테스트를 먼저 작성하고, 이를 통과하도록 만드는 최소한의 프로덕션 코드를 추가하는 방식이다. 복잡함은 이 단위가 아니라 더 큰 단위에서 생긴다. 이를 고려한 설계가 충분히 이루어지지 않은 채 TDD를 적용하면, 큰 그림을 놓칠 위험이 있다고 생각한다.

 

물론 TDD 사이클 안에서 이런 문제를 조기에 발견하는 것은 쉬울 것이다. 하지만 이렇게 되면 초기부터 작성한 많은 코드를 다시 지우는 일이 반복될 수도 있는데, 그렇다면 애초부터 너무 작은 단위의 테스트를 먼저 작성하는 과정이 꼭 필요한지 의문이 든다.

---

분할은 쉽지만, 병합은 어렵다

문제는 나뉘고, 병합된다

 

작은 단위로 나누는 것은 비교적 쉽지만, 이를 다시 병합할 때 예상치 못한 복잡성이 발생할 수 있다. 즉, 개별적으로 성공한 테스트라도 이들 간의 연결을 고려하지 않았다면 문제가 생길 수 있다.

 

예를 들어, 병합 정렬(Merge Sort)에서 문제를 나누는 것보다 합치는 과정이 복잡하듯이, 단순히 작은 문제로 나누는 것보다는 이후를 고려해 나누는 것이 더 중요할 수 있다고 생각한다.

 

---

초기에 시행착오가 많아질 가능성

TDD는 처음부터 의도적으로 실패하는 테스트를 작성하고, 이 테스트를 통과하기 위한 최소한의 코드만 작성하도록 권장한다. 이런 접근 방식은 불필요한 시행착오를 유발하고, 결과적으로 버려지는 코드가 많아질 가능성이 있다.

 

더욱이, 리팩토링의 적절한 시점에 대해서는 뚜렷한 기준이 없다. 리팩토링을 언제 해야 할지는 결국 개발자의 역량이나 성향에 달려 있는데, 이는 코드 품질을 일정하게 유지하는 데 어려움을 줄 수 있다.

예를 들어, sum(int x, int y)의 반환 값을 단순히 2로 설정하고 sum(1,1)이 2 임을 만족하는 테스트만을 통과하게 한 후, 다음 단계(sum(1,2))의 테스트가 추가되기 전까지 리팩토링을 미룰 수도 있다. 이런 부분에서 리팩토링의 시점이 지나치게 자율적이라 일관된 품질 관리가 어려워질 수 있다고 생각한다.

---

결론

물론 TDD 자체가 문제라는 것은 절대 아니다.

 

충분한 설계가 선행되었거나, 이미 자리를 잡은 프로젝트에서는 효과적인 방식일 수 있다고 생각한다. 다만, 이런 상황에서도 굳이 TDD가 권장하는 아주 작은 단위의 주기를 무조건 따라야 하는지에 대해서는 여전히 회의적이다.

 

내가 선호하는 방식은 다음과 같다.

• 전체적인 설계를 깊이 고민한 후 구현을 시작.
• 테스트는 적절한 크기로 묶어서 진행할 수 있다. (단일 테스트가 큰 것보다는, 작은 테스트 여럿을 한 번에 작성하는 방식)

이러한 방식을 통해 설계를 충분히 반영하면서도, 불필요한 리팩토링과 시행착오를 최소화할 수 있다고 생각한다.

 

또한 프로덕션 코드가 먼저 작성될 수도 있다고 생각한다. 테스트 코드 작성을 강제하기 위한 방법으로 반드시 TDD를 택하기보다는, 소나 큐브와 같은 정적 코드 분석 도구를 활용하여 커버리지를 포함한 코드 품질을 관리하는 것도 좋은 방법이 될 수 있지 않을까?

 

TDD가 그 자체로 설계 도구라는 자료를 읽어보기도 했다. 그럼에도, 설계가 충분히 이뤄지지 않은 상태에서 TDD 사이클로 개발을 시작하는 것에 대해선 우려가 있다. 작은 테스트부터 시작하여 점진적으로 설계가 드러난다고 해도, 과연 그렇게 만들어진 설계가 장기적으로 유지보수하기 좋은 구조인지 확신하기 어렵기 때문이다.

 

물론 때로는 문제가 너무 복잡하거나 모호해서 설계가 어려울 수 있다. 이런 경우 작은 테스트를 반복하며 점진적으로 문제에 대한 이해도를 높이는 것이 유효한 전략임에 동의한다.

---

참고 자료

 

https://news.hada.io/topic?id=19431&utm_source=slack&utm_medium=bot&utm_campaign=T02BHKQ35

클린 코드 vs. 소프트웨어 설계 철학 | GeekNews

 

https://github.com/johnousterhout/aposd-vs-clean-code/blob/main/README.md

aposd-vs-clean-code/README.md at main · johnousterhout/aposd-vs-clean-code

 

https://brunch.co.kr/@jowlee/176

TDD에 대한 두권의 책 비교

 

그리고 여러 크루들과 코치들!