1장의 사용자 스토리 정의하기에서 만든 목록의 첫 번째 스토리는 ‘하나의 할 일 목록을 본다’이다. 하지만 이를 구현하는 코딩을 시작하기 전에 테스트를 작성해야만 한다. 더 정확히 말하면, 소프트웨어가 고객의 인수 조건을 만족하는지 결정해주는 인수 테스트를 작성해야 한다¹.

하지만 문제가 있다. 아직 애플리케이션이 어떻게 작동할지에 대한 명확한 개념이 서 있지 않기 때문에 잘못된 테스트를 작성하느라 시간을 허비할 위험성이 있다. 이 문제는 모든 프로젝트를 시작할 때마다 발생하는 공통적인 문제다. 스티브 프리먼(Steve Freeman)과 냇 프라이스(Nat Pryce)는 다음과 같이 말한다.

첫 번째 인수 테스트를 작성할 때 곤란한 점은, 인수 테스트를 위한 도구와 특성을 동시에 구축하기가 어렵다는 데 있다. (…) 우리는 이 ‘첫 번째 특성의 모순’을 두 가지 더 작은 문제로 분리해서 헤쳐나갈 수 있다. 먼저 ‘작동하는 골격’을 만들고, 배포하고, 테스트하는 방법을 생각해낸다. 그 후 이렇게 만든 인프라를 가지고 첫 번째 의미 있는 특성에 대한 인수 테스트를 작성한다. 이렇게 하고 나면 시스템의 나머지 부분을 테스트 주도 개발로 만들기 위한 모든 준비가 끝난다.