코드를 쓰기 전에 실패하는 자동화된 테스트부터 쓰고, 그 테스트를 통과시킨 뒤 중복을 없애는 짧은 주기를 반복하는 개발 방식. 켄트 벡이 정리했다.
리듬
- 테스트를 하나 빠르게 추가한다
- 모든 테스트를 돌려 새 테스트가 실패하는지 확인한다(레드, Red)
- 통과할 만큼만 코드를 고친다(그린, Green)
- 모든 테스트가 통과하는지 확인한다
- 리팩터링으로 중복을 없앤다(리팩터, Refactor)
초록색으로 가는 세 가지 방법
- 가짜로 구현하기(Fake It): 일단 상수를 돌려줘 통과시키고, 상수를 변수로 바꿔 가며 일반화한다
- 삼각측량(Triangulate): 예제를 두 개 이상 만들어야 일반화한다. 어떻게 일반화할지 확신이 없을 때 쓴다
- 명백한 구현(Obvious Implementation): 뻔하면 바로 제대로 짠다. 막히면 다시 작은 단계로 돌아간다
핵심은 늘 작은 단계를 밟는 것이 아니라 작은 단계를 밟을 수 있는 능력이다. 길이 미끄러우면 보폭을 줄이고 상황이 좋으면 늘린다. 떠오르는 할 일은 바로 하지 않고 목록(To-Do List)에 적어 둔다.
왜 중복인가
켄트 벡은 의존성이 문제 자체라면 중복은 그 증상이라고 본다. 테스트 코드와 실제 코드 사이의 중복까지 없애다 보면 설계가 따라 나온다. 그래서 TDD는 테스트 기법이자 설계 기법이다. 심플 디자인의 첫 규칙이 "테스트를 모두 통과한다"인 것도 같은 맥락이다.
- 테스트를 먼저 쓰면 구현보다 인터페이스(어떻게 쓰일지)를 먼저 생각하게 된다
- 남은 테스트들은 리팩터링의 안전망이 된다(자가 테스트 코드)
- 버그를 고칠 때도 그 버그를 재현하는 실패 테스트부터 쓴다
컴포넌트 단위로 적용할 때는 React Testing Library, API는 DRF API 테스트을 참고.
출처: 『테스트 주도 개발』 켄트 벡 (원서 Test Driven Development: By Example)