테스트 주도 개발은(는) 무엇을 하나요?
기능을 구축하고 버그를 수정할 때, 테스트를 피드백 루프로 활용하여 한 번에 하나의 수직 슬라이스씩 작업합니다.
핵심 원칙
테스트는 구현 세부 사항이 아닌 퍼블릭 인터페이스를 통해 동작을 검증합니다. 리팩터링 후 동작 변경 없이 테스트가 깨졌다면, 그 테스트가 잘못된 것입니다.
안티패턴: 수평 슬라이스
모든 테스트를 먼저 작성한 후 모든 구현을 작성하지 마십시오. 하나의 테스트를 작성하고 통과시킨 후 반복하세요.
잘못된 예: RED test1, test2, test3 -> GREEN impl1, impl2, impl3
올바른 예: RED test1 -> GREEN impl1 -> RED test2 -> GREEN impl2 -> ...
워크플로
1. 계획
- 사용자와 인터페이스 변경 사항을 확인합니다.
- 어떤 동작을 테스트할지 확인합니다. 모든 것을 테스트할 수는 없습니다.
- 동작을 구현 단계가 아닌 관찰 가능한 결과로 나열합니다.
- 코드를 작성하기 전에 사용자의 승인을 받습니다.
2. 트레이서 불릿
하나의 동작에 대한 하나의 테스트를 작성합니다. 실패하는 것을 확인합니다. 통과하기 위한 최소한의 코드를 작성합니다.
3. 점진적 루프
남은 각 동작에 대해:
- 다음 테스트를 작성합니다.
- 최소한의 코드로 통과시킵니다.
- 미래의 테스트를 예측하지 마십시오.
4. 리팩터링
모든 테스트가 통과한 후:
- 중복을 제거합니다.
- 모듈을 심화합니다: 작은 인터페이스, 깊은 구현.
- 각 리팩터링 단계 후 테스트를 실행합니다.
RED 상태에서는 절대 리팩터링하지 마십시오.
각 사이클 체크리스트
- 테스트가 구현이 아닌 동작을 설명합니다.
- 테스트가 퍼블릭 인터페이스를 사용합니다.
- 테스트가 내부 리팩터링 후에도 유지됩니다.
- 코드가 이 테스트를 위해 최소화되었습니다.
- 추측성 기능이 추가되지 않았습니다.
규칙
- 새로운 동작에 대해 구현 전에 테스트를 작성합니다.
- 타입 힌트와 명확한 이름을 사용합니다.
- 함수를 작고 단일 목적으로 유지합니다.
- 명확한 오류 메시지와 함께 빠르게 실패합니다.