👉 TDD란?
-
Test Driven Development 의 약자로 , 테스트 주도 개발을 의미함.
-
작은 단위의 테스트 코드들을 작성, 실행시켜 미리 코드의 실패,통과 여부를 확인하고 반복하여 나온 코드로 실제 코드 작성하는데 도움.
-
실제 코드 작성 시 버그를 줄여줌.
-
불필요한 설계 피할 수 있고, 코드가 간결해짐. (=재설계 시간 단축)
-
애자일 방법론 중 하나인 eXtream Programming(XP)의 ‘Test-First’ 개념에 기반을 둔 단순한 설계를 중요시
-
보다 튼튼한 객체 지향적인 코드 생산
: TDD = 코드의 재사용 보장 = 철저한 모듈화
: 종속성 + 의존성이 낮은 모듈로 조합된 개발을 가능하게 함
= 필요에 따라 모듈을 추가 or 제거해도 전체 구조에 영향X -
자신감(ㅋㅋ귀엽)을 줌.
👉 TDD 개발 방식의 단점
- 생산성 저하
: 처음부터 2개의 코드를 짜야하고 중간중간 테스트를 하면서 고쳐야 함.
(TDD 방식의 개발 시간은 일반적인 개발 방식에 비해 대략 10~30% 정도로 늘어난다.) - 품질보다 속도, 납기일이 훨씬 중요한 프로젝트에서는 위와 같은 이유로 TDD 방식을 잘 사용하지 않음.
eXtream Programming(XP)
: 미래에 대한 예측을 최대한 하지 않고 지속적으로 프로토타입을 완성하는 애자일 기방법론 중 하나.
추가 요구사항이 생기더라도 실시간으로 반영할 수 있다.
👉 TDD 개발주기
-
RED : 실패하는 테스트 코드를 먼저 작성
(실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 말 것.) -
GREEN : 테스트 코드를 성공시키기 위한 실제 코드를 작성
(실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성) -
BLUE : 중복 코드 제거, 일반화 등의 리팩토링 수행
👉 테스트는 유연성, 유지보수성, 재사용성을 제공함.
: 단위테스트 = 코드에 유연성, 유지보수성, 재사용성을 제공함.
-> 테스트케이스로 확인하고 실제 코드를 변경하면 되니까.
👉 TDD 법칙 세 가지
(이외에도 중요한 점 많긴 함. 찾아볼 것. )
1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
2. 컴파일은 실패하지 않으면서, 실행이 실패하는 정도로만 단위 테스트를 작성한다.
3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
👉 깨끗한 테스트 코드
: 최소의 표현으로 많은 양을 나타내야함 = 가독성이 중요
(= 명료성 + 단순성 + 풍부한 표현력(?))
지저분한 테스트코드는 테스트를 하지 않는 것이나 다를 바 없음.
실제 코드가 진화하면 테스트 코드도 변해야한다.
테스트 코드가 지저분하면 실제 코드보다 테스트 코드를 짜는 시간이 더 길어질 수있음;;
- 불상사 발생 : 테스트코드 지저분 -> 케이스 불통 -> 테스트코드 추가 -> ... -> 계속 늘어남.
