Development

GitHub에서 파일 변경이 50개, diff 라인이 2,000줄을 넘는 PR을 받아본 팀이라면 공통적인 경험을 압니다. 리뷰어는 PR을 열었다가 스크롤을 한두 번 내리고 "나중에 봐야지"라고 탭을 닫습니다. 그리고 그 PR은 사흘, 일주일, 길게는 2주를 방치됩니다.

유닛 테스트와 통합 테스트는 로직과 데이터 흐름을 검증합니다. expect(price).toBe(9900) 같은 assertion은 숫자가 맞는지 확인하지만, 그 숫자가 화면에서 어떤 크기로 렌더링되는지는 전혀 알 수 없습니다. 비주얼 버그는 다양한 경로로 발생합니다.

구분 유닛 테스트 통합 테스트 ------ ------------ ------------ 검증 대상 함수/훅/순수 컴포넌트 컴포넌트 조합 + API 흐름 의존성 처리 완전 모킹 네트워크 레이어만 인터셉트 실행 속도 매우 빠름 빠름 버그 검출 범위 로직 오류 통합 오류, 상태 전이 오류 유지보수 비용 구현 변경 시 깨지기 쉬움 인터페이스 기반, 상대적으로 안

TDD의 핵심은 피드백 루프를 극단적으로 짧게 가져가는 것입니다. 1단계: 실패하는 테스트 작성 (Red) 가장 작고 단순한 변화부터 시작합니다. 아직 구현하지 않은 기능에 대한 테스트를 작성하여, 의도적으로 실패하게 만듭니다. 이 단계에서는 '기능이 어떻게 동작해야 하는가'라는 사용자 관점의 명세(Specification)에 집중합니다.

TDD는 단순히 테스트를 많이 짜는 것이 아닙니다. 생각의 순서를 바꾸는 훈련입니다. 그 핵심에는 Red-Green-Refactor 라는 리듬이 있습니다. 1.1 Red: 실패하는 테스트 작성 많은 개발자가 구현 코드를 머릿속에 그리며 테스트를 작성합니다.