TDD(Test Driven Development) - 테스트 주도 개발
* Production Code
실제 배포하는 코드. 서비스 코드를 일컫는다.
* Test Code
문자 그대로 테스트하는 코드를 일컫는다.
TDD란?
TDD = TFD(Test First Development) + 리팩토링
단위 테스트와 TDD를 같다고 생각하는 경우가 있는데, 단위 테스트와 TDD는 다른 용어이다.
* 단위 테스트
단위 테스트는, Production Code를 만든 뒤에 자동화된 단위테스트 코드를 만들 수 있다.
* TDD
TDD는 Production Code를 구현하기 전에 단위테스트 코드를 먼저 추가하는 것이다.
TDD는 테스트 코드를 무조건 Production Code보다 먼저 구현해야 하는 원칙이 있다.
테스트 코드를 먼저 구현하는 것이 중요한 것이 아니고, TDD 싸이클을 돌리는 과정에서 리팩토링하는 과정이 중요하다.
리팩토링: 설계 활동. 기능에 대한 변경은 없으면서 클래스나 메서드를 분리하는 등의 설계 활동을 말한다.
설계를 한번에 몰아서 하는 것이 아니라, 테스트 케이스 하나를 추가하고, 그 사이클 내 설계 작업을 지속적으로 하자는 취지이다. 작은 단위로 기능이 추가 될 때마다 설계를 계속 개선해 나가자는 취지로 탄생하게 된 것이다.
TDD란 프로그래밍 의사결정과 피드백 사이의 간극을 의식하고 이를 제어하는 기술이다.
TDD의 아이러니 중 하나는 테스트 기술이 아니라는 점이다. TDD는 분석 기술이며, 설계기술이기도 하다.
- 켄트벡, Test Driven Development by Example 중
TDD를 잘하기 위해선, toDoList가 잘 정리 되어 있어야한다. todoList가 잘 정리됐다는 것은 요구사항 분석을 잘 했다는 의미이다.
* TDD를 하는 이유
- 디버깅 시간을 줄여준다.
- 동작하는 문서 역할을 한다.
- 변화에 대한 두려움을 줄여준다.
* TDD 사이클
- 실패하는 테스트를 구현한다.
- 테스트가 성공하도록 프로덕션 코드를 구현한다.
- 프로덕션 코드와 테스트 코드를 리팩토링 한다.
3단계의 사이클을 계속 반복하는 것.
이 사이클을 유지하면서 프로그래밍하는게 굉장히 어렵다.
* TDD 원칙
원칙1 - 실패하는 단위 테스트를 작성할 때까지 프로덕션 코드(production code)를 작성하지 않는다.
원칙2 - 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
원칙3 - 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
한번에 너무 많은 부분을 예측해서 개발하지 말고 현재 테스트 케이스를 만족할 수 있는 수준으로만 production code를 개발하라. 오버 엔지니어링하지 않고 필요한 정도로만 production code를 구현하라.
