2-3. TDD 절차

해당 포스트는 이규원님의 "Spring Boot TDD" 강의를 기반으로 작성하였습니다.

Spring Boot TDD - 입문부터 실전까지 정확하게| 이규원 - 인프런 강의

---

TDD 소개: 프로그래머를 위한 실용적 접근

프로그래머로서 우리는 소프트웨어 개발에서 테스트를 통해 품질을 높이는 방법을 자주 고민합니다. TDD(Test-Driven Development)는 Kent Beck이 과거 프로그래밍 사례를 기반으로 만든 방법론으로, 코드 작성 전에 테스트를 우선하는 접근입니다. TDD는 환경에 따라 추가 요소가 필요하지만, 기본 절차 자체는 단순합니다. 이 글에서는 TDD의 배경부터 시작해 절차 개요와 각 단계를 서론부터 상세히 설명하겠습니다. 이를 통해 TDD가 어떻게 코드 품질과 개발 효율을 높이는지 이해하기 쉽게 풀어보겠습니다. TDD는 연습을 통해 익힐 수 있는 기술로, 요구사항 충족과 코드 유지보수성을 강조합니다.

 

1. TDD의 배경: 테스트 중심 개발의 필요성

TDD는 코드 작성 전에 테스트를 만들어 요구사항을 명확히 하고, 변경에 강한 소프트웨어를 만드는 방법입니다. Kent Beck의 경험에서 나온 이 접근은, 기능 구현 전에 실패 테스트를 작성해 코드의 안정성을 보장합니다. TDD는 복잡한 환경에서 효과를 발휘하지만, 기본 절차는 직관적입니다. 핵심은 "테스트가 코드를 이끈다"는 철학으로, 개발 과정에서 확신을 쌓아갑니다.

 

2. TDD 절차 개요

TDD는 기능 추가나 개선 시 반복되는 사이클로 진행됩니다.

• 테스트 시나리오 목록 작성: 기능에 대한 모든 시나리오(성공·실패 케이스)를 나열.
• 하나의 시나리오 테스트 코드 작성: 목록에서 하나 선택해 실행 가능한 테스트 코드로 변환.
• 테스트 통과를 위한 운영 코드 변경: 새 테스트와 기존 테스트 모두 통과하도록 코드 수정. 새로운 시나리오 발견 시 목록 추가.
• 리팩터링 (선택적): 구현 품질 개선 필요 시 코드 구조 조정.
• 완료 확인: 목록이 비워지면 종료, 남아 있으면 2단계로 반복.

 

3. TDD 단계별 상세: 실무 적용 가이드

TDD의 각 단계는 테스트 중심으로 코드가 진화하도록 설계되었습니다. 아래에서 세부 사항을 설명하겠습니다. 각 단계는 이전 단계의 결과를 바탕으로 진행되며, 전체 과정에서 코드와 테스트가 공진화합니다.

3.1 테스트 시나리오 목록 작성

TDD의 첫 단계로, 대상 기능에 대한 모든 가능한 테스트 시나리오를 목록으로 만듭니다. 이는 기능의 성공 케이스뿐만 아니라 실패 케이스도 포함합니다.

• 왜 중요한가?: 목록 작성은 요구사항을 명확히 하고, 누락된 시나리오를 미리 발견합니다. TDD의 기반이 되며, 제품 품질에 직접 영향을 줍니다.
• 실행 팁: 모든 시나리오를 brainstorm처럼 나열. 신입·주니어 개발자는 이 목록을 선임자에게 리뷰 요청하면 좋습니다. 목록은 TDD 과정뿐만 아니라 전체 개발에 활용됩니다.
• Kent Beck의 강조: 많은 사람이 이 단계를 놓치지만, TDD의 성공에 핵심적입니다. 목록이 없으면 테스트가 산발적입니다.

 

3.2 테스트 코드 작성

목록에서 정확히 하나의 시나리오를 선택해 자동화된 테스트 코드로 변환합니다. 한 번에 여러 시나리오를 처리하지 말고, 하나씩 집중합니다.

• 왜 하나씩?: 확신을 쌓고 모호함을 최소화. 여러 개 처리 시 심리적 부담 증가, 장점 없음.
• 테스트 실행 확인: 코드 작성 후 실행해 실패 확인. 예상 실패 이유(운영 코드 미변경)가 맞아야 합니다. 다른 이유 실패 시 테스트 코드나 시나리오 수정.
• 인터페이스 설계 시작: 새 기능 시 테스트가 인터페이스의 첫 클라이언트 역할. 인터페이스 초안이 여기서 자연스럽게 도출됩니다.
• 실행 팁: 독립 작업 시 테스트 목록과 인터페이스 초안을 동시에 작성. 둘의 상호작용으로 더 나은 설계가 나옵니다. 협업 시 미리 합의된 인터페이스(예: API 계약) 기반으로 진행.

 

3.3 테스트 통과를 위한 코드 변경

새 테스트와 기존 모든 테스트를 통과하도록 운영 코드를 수정합니다. 요구사항 만족에 집중합니다.

• 왜 모든 테스트?: 기존 기능 회귀 방지. TDD의 안전망 역할.
• 새 시나리오 발견 시: 목록에 추가하고 계속 진행. 구현 중 누락된 부분 보완.
• 실행 팁: 테스트 통과 후 해당 시나리오에 완료 표시. 제품 개발의 핵심 목표(기능 구현)를 최우선으로.

 

3.4 리팩터링 (선택적 단계)

테스트 통과 후 구현 품질 검토. 필요 시 리팩터링으로 코드 구조 개선합니다.

• 왜 선택적?: 항상 필요하지 않음. 판단 기준: 코드 어지러움 vs 과도한 추상화 위험.
• 주의점: 리팩터링 후 모든 테스트 재실행. 실수 방지.
• 실행 팁: 과도 방치 피함(후속 정리 어려움), 성급 추상화 피함(불필요 비용 발생). 균형이 핵심.

 

3.5 테스트 시나리오 완료 확인

목록의 모든 시나리오가 완료되었는지 확인합니다.

• 완료 시: 작업 종료.
• 미완료 시: 2단계로 반복.
• 왜 반복?: 모든 시나리오 커버로 기능 완성 보장.

 

4. TDD의 전체적 이점과 주의점

TDD는 단순한 절차지만, 연습으로 익히면 코드 품질이 크게 향상됩니다. 테스트가 요구사항을 구체화하고, 변경 시 안정성을 제공합니다. 그러나 테스트 목록 작성을 소홀히 하면 효과가 줄어듭니다. 실무에서 TDD는 제품 품질뿐만 아니라 개발자 확신을 쌓는 도구입니다.

• 주의점: TDD는 도구, 환경에 따라 조정. 강의 실습에서 직접 경험하세요.

이 절차를 따르면 프로그래밍이 더 체계적이고 안전해집니다!