TDD
태그 :
- 개념
- - Simple Code의 추구를 목적으로 Test Case를 먼저 개발하고 Test Case를 통과하는 실제코드를 나중에 개발하는 Agile 개발방법 - 테스트 작성으로 요구사항 검증, 설계의 고도화, 짧은 주기 Life Cycle을 반복하는 테스트-설계-피드백 중심 개발사고 방식/방법론
I. 테스트 중심 개발 (Test-driven development)의 개요
가. 테스트 중심 개발(TDD)의 정의
- Simple Code의 추구를 목적으로 Test Case를 먼저 개발하고 Test Case를 통과하는 실제코드를 나중에 개발하는 Agile 개발방법
- 테스트 작성으로 요구사항 검증, 설계의 고도화, 짧은 주기 Life Cycle을 반복하는 테스트-설계-피드백 중심 개발사고 방식/방법론
나. 테스트 중심 개발(TDD)의 특징
- Design for Testability: 소스코드의 의존성이 감소하고 독립적인 테스트가 가능한 설계구조
- 테스트 커버리지 확보: 단위테스트를 통한 테스트 커버리지 유지, 디버깅 시간감소
- 기능에 집중: 기능위주의 테스트 작성으로 해당 기능의 견고성이 증가
- clean code that works: 작동하는 깔끔한 코드 지향
II. 테스트 중심 개발 (TDD)의 사이클
가. 테스트 중심 개발(TDD)의 사이클
구분 |
내용 |
사용자 요구사항 |
사용자, BA, 제품 개발자 등이 요구사항 Story 작성 |
Test Case |
사용자, Tester 등 관련자들이 Test Case를 마련 Detail하게 작성 |
Code 작성 |
테스트에 대해 실행 가능한 코드를 빠르게 작성 (임시코드/자료삽입, 가짜 구현, 명백한 구현) |
Refactoring |
Bad small을 제거하여 Refactoring 수행 후 Simple code에 대한 Test 수행 |
- 짧은 구현, 많은 반복을 통한 개발 위해 테스트 사이 간격 조절 능력 필요
나. TDD에서 사용하는 패턴
구분 |
내용 |
빨강막대패턴 |
테스트를 언제, 어디에 작성할 것인지, 언제 멈출 것인지 결정 |
테스트 패턴 |
상세한 테스트 작성(자식/모의객체/Self-shunt/메시지 호출) |
초록막대패턴 |
코드가 테스트를 통과하도록 신속하게 작동하는 코드 작성 |
xUnit패턴 |
자동화된 단위테스트 지원 프레임워크(jUnit, CppUnit, PyUnit) |
디자인패턴 |
검증된 해결책, 설계 Template/Best Practice |
다. 효과적 수행방법
- Automatic: 테스트가 혼자 실행, 자신을 검증할 수 있어야 함
- Through: 철저함, 문제 영역에 대한 완벽한 테스트 지원
- Repeatable: 반복가능, 같은 결과 도출
- Independent: 하나의 대상에 집중, 독립적 상태 유지, 다른 테스트 의존 안 함
- Professional(전문적): 캡슐화, 낮은 결합도의 원칙이 테스트 코드에서도 지켜져야 함
III. TDD적용시 예상되는 장애요소, 제거방안
가. TDD적용시 예상되는 장애요소
구분 |
장애요소 |
설명 |
사용자요구 |
빈번한 요구사항 변경 |
요구분석 및 요구사항 변경은 과도한 테스트케이스 변경, 반복적인 소스코드 변경 수반 |
테스트설계 |
테스트케이스의 독립성 확보 어려움 |
- 실제 코드 개발 이전에 진행되기에 반복적인 소스코드의 변경은 테스트 케이스의 변경을 발생시킬 수 있으며 연관된 테스트 케이스에 영향 - 개발초기 전체 커버리지를 맞먹는 테스트 케이스가 도출될 때 |
코드작성 |
유닛 테스트의 자동화툴 지원 및 툴의 유연성 |
- 테스트 자동화는 TDD에서 필수조건 - 테스트가 자동화되지 않으면 테스트에 드는 시간이 증가되어 개발주기에 맞춰 진행 어려움 - 개발언어별 유닛 테스트 도구의 지원이 부족할 수 있음 |
리팩토링 |
반복적인 회귀테스트 |
- 빈번한 테스트케이스 변경에 대해서 자동화 툴이 유연하고 신속하게 지원할 수 없을 경우 반복되는 테스트를 효율적 관리 어려움 - 지루하고 기계적인 과정으로 변질 가능 |
나. TDD의 장애요소 제거방안
장애요소 |
제거방안 |
설명 |
요구변경 |
요구공학, 형상관리 |
TDD는 빠른 개발을 목표로 하지만 엔터프라이즈 급의 대규모 시스템 적용 시에는 요구공학 등의 공학적인 요구사랑 관리 기법 필요 |
테스트케이스 |
테스트 전문가 활용 |
독립된 QA조직의 운영은 개발자에 의해 이루어지는 단위 테스트 작업에서 발생할 수 있는 다양한 이슈 해결 가능 |
Unit테스트 |
자동화 툴 사용 |
테스트 드라이버: 테스트 스크립트와 테스트 데이터를 이용해 테스트 수행 전체를 주관 테스트 스텁: 미 구현된 유닛 부분을 대체하여 인터페이스 제공 테스트 환경: 테스트 특정 상황 제공 또는 재현 테스트 결과: 테스트 결과에 대한 로그 분석 |
리팩토링 |
유닛 테스트 툴 |
개발언어에 맞는 유닛테스트 툴을 이용하여 반복적인 테스트작업 |
IV. ATDD(Acceptance TDD) 및 그린코드
1) 전체 시스템 관점에서TDD는 개별 단위 모듈 레벨의 내부 품질 검증(하위레벨)이 주목적이라면 ATTD는 외부 품질(시스템 품질) 검증(상위레벨)으로 TDD를 포함하여 기능 테스트 수준까지 확장
2) 그린코드 (Green Code)
가. 정의
모든 테스트 케이스를 성공적으로 통과하고 높은 품질 및 안정성이 확보된 검증된 모듈
나. 그린 코드 구현 요건
- 개발 시간 단축: 조기 오류 검출 및 제거를 통한 개발 시간 단축
- 개발 비용 절감: 동적, 정적 분석 자동화 도구를 활용한 품질 테스트 효율 향상
- 고품질 SW구현: 프로그램 완성도 향상으로 기대 품질 유지 및 향상
다. 선제적 오류 제거를 위한 그린 코드 구현 전략
전략 |
설명 |
도구 및 기법 |
정적 테스트 |
개발 사전 혹은 병행 실시하여 오류 조기 검출 및 제거 |
인스펙션, 리뷰, 정적 프로그램 분석, 실행 기반 의미 분석 기법 적용 |
테스트 효율행상 |
자동화 도구 도입을 통한 효율 향상 |
McCabe, SPARROW 등 도구 활용 및 TDD선별 적용 |
SW품질 가시화 |
SW품질 및 테스트 진행 현황 가시화 수행 결과 및 통계 리포트 생성 |
테스트 모니터링 대시보드 구현 지속적인 통합(CI) 연계 및 일일빌드 활성화 조기 경보 시스템 운영 |
품질관리 체게 |
엄격한 품질 관리 체계를 수립하여 지속적인 품질 관리 실시 |
SW신뢰성 평가, 인증 실시, 성숙도 측정 |
- 리뉴와 인스펙션을 통해서도 30~70% 오류 사전 검출 및 예방, 정적 분석 도구 활용시 효과 극대화