[Test] TDD(Test Driven Development)

TDD: 테스트가 개발을 이끈다?

우리는 지금까지 테스트의 필요성과 단위 테스트 작성법에 대해 알아봤다. 이번에는 한 걸음 더 나아가, 아예 개발 프로세스 자체를 뒤집어보는 '테스트 주도 개발(TDD)'에 대해 이야기해보려 한다.

TDD(Test Driven Development)란?

TDD는 말 그대로 프로덕션 코드보다 테스트 코드를 먼저 작성해서, 테스트가 전체 구현 과정을 이끌어가는 개발 방법론이다.

"코드를 짜기도 전에 테스트를 어떻게 만들어?" 싶겠지만, TDD는 아주 구체적이고 체계적인 단계를 따른다.

TDD의 심장: RED-GREEN-REFACTOR 사이클

TDD는 아래 3단계를 끊임없이 반복하며 진행된다.

1. 실패하는 테스트부터 작성한다 (RED)
   • 우선 "이 기능은 이렇게 동작해야 해"라는 기대를 담아 테스트 코드를 작성한다.
   • 당연히 실패한다. 아직 이 테스트를 통과시킬 프로덕션 코드가 아예 없기 때문이다.
2. 테스트를 통과시킨다 (GREEN)
   • 이제 방금 작성한 RED 상태의 테스트를 통과시킬 최소한의 코드를 작성한다.
   • 이 단계의 목표는 오직 '테스트 통과'다. 일단 돌아가게만 만들면 된다. 코드가 좀 지저분해도, 비효율적이어도 괜찮다.
3. 코드를 개선한다 (REFACTOR)
   • 테스트가 GREEN 상태로 유지되는 것을 확인하면서, 프로덕션 코드의 구조를 개선한다.
   • 이제 '돌아가는' 코드를 '좋은' 코드로 만든다. 중복을 제거하고, 가독성을 높이는 등의 작업을 한다.

이 RED-GREEN-REFACTOR 사이클을 계속해서 반복하며 소프트웨어를 점진적으로 완성해나가는 것이다.

왜 굳이 이렇게 거꾸로 일해야 할까?

TDD의 핵심 가치는 빠르고 잦은 피드백에 있다. 기존의 '선 기능 구현, 후 테스트 작성' 방식의 문제점을 생각해보면 TDD의 장점이 명확해진다.

기존 방식 (선 기능 구현, 후 테스트)의 문제점

• 테스트 자체를 빼먹기 쉽다. ("일단 기능만 만들고 테스트는 나중에..." 하다가 결국 못 하고 넘어가는 경험, 다들 있지 않은가?)
• 해피 케이스만 검증하게 된다. 내 코드가 잘 돌아갈 거라는 긍정적인 상상에 갇혀 엣지 케이스를 놓치기 쉽다.
• 잘못된 구현을 너무 늦게 발견한다. 한참 개발하고 나서야 "아, 이거 설계가 잘못됐네" 하고 깨닫게 된다.

TDD 방식 (선 테스트, 후 기능 구현)의 장점

• 자연스럽게 테스트 가능한 코드를 짜게 된다. 테스트를 먼저 생각하니, 어떻게 하면 외부 의존성을 분리하고 코드를 유연하게 만들지 고민하게 된다.
• 놓치기 쉬운 엣지 케이스를 잡을 수 있다. 다양한 시나리오의 테스트 케이스를 먼저 고민하기 때문이다.
• 구현에 대한 즉각적인 피드백을 얻는다. 코드를 한 줄 고칠 때마다 테스트가 바로 알려준다.
• 자신감을 갖고 리팩토링할 수 있다. 든든한 테스트 코드가 내 뒤를 받쳐주니, 과감한 개선이 가능해진다.

TDD: 단순한 기술이 아닌, 관점의 변화

TDD를 도입하면 개발을 바라보는 관점 자체가 바뀐다.

기존에 테스트는 '구현 코드를 검증하는 보조 수단'이었다면, TDD에서 테스트는 구현부와 상호작용하며 함께 발전하는 파트너다. 마치 내 코드를 사용할 첫 번째 클라이언트(사용자)가 되어 즉각적으로 피드백을 주는 것과 같다.

TDD는 단순히 버그를 줄이는 기술을 넘어, 더 나은 설계와 지속 가능한 소프트웨어를 만드는 개발 방법론이다.

---

Ref) Practical Testing: 실용적인 테스트 가이드 강의 | 박우빈 - 인프런