일반적인 개발 과정을 생각해 봅시다. 개발자는 먼저 제품 코드를 길게 작성하고, 그 코드가 잘 동작하는지 눈으로 확인하거나 직접 실행해 봅니다. 그리고 시간이 남는다면, 나중에 테스트 코드를 추가할지도 모릅니다.
그런데 만약 이 순서를 완전히 뒤집는다면 어떨까요?
실제 제품 코드를 작성하기 전에, 그 코드가 통과해야 할 ‘실패하는 테스트 코드’를 먼저 작성하는 것입니다. 이처럼 테스트가 개발을 이끌어 나가는 방식을 TDD(Test-Driven Development, 테스트 주도 개발)라고 부릅니다. 이번 글에서는 TDD에 대해, 그리고 QA가 이를 왜 알아야 하는지에 대해 알아보겠습니다.
Q. ‘테스트 주도 개발(TDD)’, 정확히 무엇인가요?
TDD(테스트 주도 개발)는 실제 제품 코드를 작성하기 전에, 해당 코드가 만족시켜야 할 요구사항을 ‘실패하는 테스트 코드’의 형태로 먼저 작성하는 개발 방법론입니다.
이는 단순히 테스트를 먼저 하는 행위를 넘어, 테스트를 통해 소프트웨어의 설계를 점진적으로 개선해나가는 ‘개발 철학’에 가깝습니다.
Q. TDD의 핵심 사이클, ‘Red-Green-Refactor’는 무엇을 의미하나요?
테스트 주도 개발은 ‘빨강-초록-리팩터’라는, 매우 짧고 반복적인 사이클을 통해 진행됩니다. 개발자는 이 사이클을 수십, 수백 번 반복하며 소프트웨어를 점진적으로 완성해 나갑니다.
- Red (빨강): 실패하는 테스트 작성
- 가장 먼저, 앞으로 개발할 기능에 대한 ‘실패’하는 단위 테스트 코드를 작성합니다. 아직 해당 기능을 구현한 제품 코드가 전혀 없기 때문에, 이 테스트를 실행하면 당연히 실패하고 결과는 ‘빨간불’이 뜹니다.
- 이 단계의 진짜 목표는 ‘내가 지금부터 무엇을 만들어야 하는지’를 테스트 코드라는 명확한 형태로 스스로에게 정의하는 것입니다.
- Green (초록): 테스트를 통과하는 코드 작성
- 이제 방금 작성한 ‘빨간불’의 테스트를 통과시킬 수 있는 ‘최소한’의 제품 코드를 작성합니다. 이 단계에서는 코드의 구조가 아름답거나 효율적이지 않아도 괜찮습니다. 오직 테스트를 통과시켜 ‘초록불’로 빠르게 바꾸는 것만이 유일한 목표입니다.
- Refactor (리팩터): 코드 개선
- 테스트가 ‘초록불’이 되어, 내 코드가 최소한의 요구사항을 만족한다는 ‘든든한 안전망’이 생겼습니다.
- 중복된 코드를 제거하고, 변수 이름을 명확하게 바꾸는 등 ‘클린 코드’ 원칙에 따라 코드를 더 읽기 좋고 유지보수하기 쉽게 만드는 과정입니다.
Q. QA가 직접 코딩하는 것도 아닌데, TDD를 왜 알아야 하나요?
TDD는 개발 문화이며, QA는 이 문화를 이해하고 활용할 때 팀 전체의 품질을 한 단계 끌어올리는 시너지를 낼 수 있습니다.
- 높은 코드 품질에 대한 신뢰:
- 개발팀이 TDD를 실천하고 있다는 것은, QA에게 코드가 전달되기 전에 이미 수많은 단위 테스트를 통해 코드의 가장 작은 단위부터 품질이 검증되었음을 의미합니다. QA는 이를 신뢰하고, 기능의 세세한 부분보다는 여러 기능이 복잡하게 얽히는 통합 테스트나 사용자 시나리오 기반의 E2E 테스트에 더 집중할 수 있습니다.
- 명확한 요구사항 기반의 소통:
- TDD에서 작성된 단위 테스트 코드들은 그 자체로 ‘실행 가능한 명세서’ 역할을 합니다. QA는 이 테스트 코드를 읽고, 개발자가 주어진 기능을 어떻게 이해하고 구현했는지 명확하게 파악할 수 있습니다.
- 버그 재현 및 수정 검증의 용이성:
- 버그가 발견되었을 때, TDD를 따르는 개발자는 해당 버그를 재현하는 ‘실패하는 단위 테스트(Red)’를 먼저 작성하고, 그 테스트를 통과하도록(Green) 코드를 수정합니다.
결론: 품질은 처음부터 만들어지는 것
TDD(테스트 주도 개발)는 단순히 테스트를 먼저 하는 기술이 아니라, 소프트웨어의 설계를 견고하게 만들고, 버그를 사전에 예방하며, 유지보수하기 좋은 코드를 만드는 개발 철학입니다.