XP는 객체지향의 대가인 켄트 벡이 창시하였으며, 혁신적인 새로운 소프트웨어 개발 방법론이다. XProgramming.com의 편집주인 론 제프리는 XP를 위한 12가지 핵심 훈련을 다음과 같이 서술하였다.
1. 계획 절차(The Planning Process) : 고객이 요구하는 비즈니스 가치를 정의하고, 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지를 알려준다.
2. 소규모 릴리즈(Small Release) : 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트한다.
3. 상징(Metaphor) : 공통적인 이름의 체계를 갖고 공통적인 시스템 서술서를 갖게 되면, 개발과 의사소통을 돕는다.
4. 단순 설계(Simple Design) : 현재의 요구사항에 들어맞는 가장 단순한 시스템을 설계한다. "미래를 위해서"라는 것은 필요 없다. 리택토링을 통해서도 좋은 설계를 할 수 있다.
5. 테스팅(Testing) : XP는 항상 소프트웨어의 적합성에 초점을 두고 있다. 개발자는 테스트를 먼저한 후에 소프트웨어를 작성한다. 그렇게 되면 이미 테스트에서 요구사항을 충족하게 된다.
6. 리팩토링(Refactrong) : 개발하는 동안 내내 시스템의 설계를 향상시킨다.
7. 짝 프로그래밍(Pair Programming) : 개발자 둘이서 짝으로 코딩한다. 짝 프로그래밍은 혼자 코딩하는 것보다 비슷하거나 혹은 더 적은 비용을 들인다고 한다.
8. 공동 소유(Collective Ownership) : 모든 코드는 모든 개발자에게 속해있다. 이는 팀을 최상의 속도로 움직이게 하며, 변경이 필요할 때에도 지연을 줄인다.
9. 지속적인 통합(Continous Integration) : 매일 여러 번씩 소프트웨어를 통합하고 빌드한다.
10. 주당 40시간 업무(40 hour Week) : 피곤한 개발자가 실수를 더 많이 한다.
11. 현장고객 지원(On site Customer) : 의사소통을 향상시키고 문서의 양을 줄일 수 있다.
12. 코딩 표준(Coding Standard) : 효과적인 공동 작업을 위해서는 모든 코드에 대한 코딩 표준을 정의한다.
한글로 선행 테스트 개발 정도로 얘기할 수 있다. 즉 실제코드를 작성하기 전에 먼저 테스트코드를 작성하고 테스트코드를 거쳐서 필요한 실제 API를 만들어 내는 것이다. 보통 테스트라고 하면 먼저 실제코드를 작성하고 이 실제코드에 버그가 있는지 잘못된 오류가 있는지를 테스트하는 것을 의미했다. 그러나 TDD는 이를 뒤집는다. 테스트코드 없이는 실제코드를 작성할 수 없다. 이렇게 완성된 코드는 간결하며 검증이 되고 명확하다.
TDD는 딱히 규정된 사용법이 없다. 경험에서 우러나오는 것이다.
TDD를 적용하기 전의 일반적인 프로그램이라면, 이미 작성된 코드기 때문에 프로그래머의 의도대로 흘러가기 쉽고, 그만큼 오류에 빠질 염려가 있다. 그러나 TDD를 사용해서 먼저 테스트코드를 만들고 빠질 수 있는 오류를 통과시키면서 개발하게 되면 따로 테스트를 반복할 필요가 없고, 이미 테스트코드가 작성되어 그 자체가 개발의 히스토리를 담고 있으므로 훌륭한 개발 문서가 된다.