TDD
TDD란?
테스트 주도 개발(test-driven development)
선 개발 후 테스트 방식이 아닌 선 테스트 후 개발 방식
기존방식의 프로세스
디자인(설계) => 개발 => 테스트 => 디자인(설계) => 개발 => 테스트
TDD
디자인(설계) <=> 테스트 => 개발 => 리팩토링 => 테스트
위와 같은 방식의 프로세스가 TDD의 형태이다.
TDD 꼭 필요한가?
라고 한다면 무조건 필요하다는 아니다.
테스트 코드를 짜는 시간도 개발 비용에 들어가게 되고 생산성 저하라는 단점이 생기게 되고 납기기한이 빡빡한 프로젝트에서 테스트를 진행하게 되면 기한을 준수하지 못하는 경우가 생기게 된다.
TDD 장점
- 객체 지향적인 코드 개발
- TDD는 코드의 재사용 보장을 명시
- TDD를 통한 소프트웨어 개발 시 기능별로 모듈화
- 의존성, 종속성 낮아짐
- 설계 수정시간의 단축
- 테스트코드를 먼저 작성하기 때문에 설계의 구조적 문제를 바로 찾아낼 수 있다.
- 유지보수 용이
- 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향을 미치치 않게 된다.
- 디버깅 시간의 단축
- TDD의 경우 자동화 된 유닛 테스팅을 전제하므로 특정 버그를 손쉽게 찾아낼 수 있다.
TDD 단점
- 생산성 저하
- 하나의 API를 작성할때 두개의 코드를 작성하게 되고 그로인해 개발시간이 늘어난다.
- 개발방식을 바꿔야한다.
- TDD방식의 개발방식의 개발을 하지 않던 개발자나 처음 개발을 입문하는 주니어개발자는 테스트코드 먼저 작성하는 개발방식에 익숙해져야 하기때문에 진입장벽이 있다.
TDD 목표
TDD의 목표는 작동하는 깨끗한 코드(Clean code that works)
TDD 아이디어를 주장한 켄트 백(Kent Beck)은
처음 실패한 자동화 코드가 없으면 새로운 코드 행을 작성하지 않는다. 그다음 중복을 제거한다고 정의했다.
클린코드가 되어가는 과정
1. Unit test 코드 작성
2. 테스트를 한다.
3. 테스트 불통과 = 테스트코드 수정, 통과 = 테스트코드 리팩토링
4. 리펙토링한 코드 테스트
6. 리펙토링한 코드가 통과 될때까지 코드를 수정
7. 테스트 통과시 다음 테스트 케이스 작성
TDD의 세 가지 규칙
클린 코드 책의 저자로 유명한 로버트 C 마틴(엉클 밥)
밥이 제시한 TDD의 세 가지의 규칙은 다음과 같다.
- 먼저 실패하는 테스트 코드를 작성한다.
- 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 테스트 코드를 작성한다.
- 현재 실패하는 테스트 코드가 통과된 코드만 실제 코드에 작성한다.
켄트 백과 밥은 세 가지 규칙을 벗어난 개발 스타일을 금기시하고 있다.
참고한 블로그
tdd란-테스트-주도-개발
선택이-아닌-필수-tdd
테스트주도개발
아자