예제는 콘텐츠 전송 네트워크(CDN)에서 재스민 파일을 가져오지만, 본인 PC에 파일을 내려받아 포함해도 좋다.

팀 내 단위 테스트 규정을 잘 따랐으니 승현은 코드를 체크인하고 자신 있게 다음 개발을 진행한다.

몇 시간 후(또는 며칠, 몇 주 후) 다른 팀에서 createReservation 함수 통합 작업을 진행 중인 동료 개발자 샬럿(Charlotte)이 메일을 보낸다. 통합 테스트 꾸러미에서 실행했더니 createReservation 함수 테스트가 모두 실패했다는 내용이다. “에이, 설마…… 내 눈으로 성공하는 걸 똑똑히 봤는데?” 승현이 회신한다.

그런데 자세히 들여다보니 단위 테스트에 오류가 보인다. 반환된 예약 객체의 속성명은 passengerInformation과 flightInformation이라고 명세에 나와 있는데, createReservation 개발을 너무 서두른 나머지 승현은 속성명을 passengerInfo와 flightInfo로 잘못 코딩한 것이다. 당연히 샬럿은 명세에 쓰여 있는 이름을 가진 속성을 전제로 테스트 코드를 작성했을 것이다.

명세가 아니라 함수 코드의 개발에 따라 테스트를 작성한 탓에 테스트는 기대하는 함수 작동이 아닌, 구현된 함수의 (잘못된) 실제 작동을 확인한 꼴이다. 명세 기준으로 테스트 코드를 작성했으면 애당초 속성명을 틀릴 일은 없었을 것이다.

테스트 기반을 현재 코드가 아니라 명세에 두는 TDD 방식으로 개발해도 이 정도 실수쯤은 일어나지 않겠냐고 할 독자도 있겠지만, 경험에 따르면 전혀 그렇지 않다.