Martin Fowler의 Refactoring을 다시 읽고 있습니다. 4 장 건물 테스트에서 다음 구절을 보았습니다.
실제로 테스트를 작성하는 가장 유용한 시간 중 하나는 프로그래밍을 시작하기 전에입니다. 기능을 추가해야 할 때 테스트를 작성하여 시작하십시오. 이 소리만큼 뒤로가 아닙니다. 테스트를 작성하면 함수를 추가하기 위해 수행해야 할 작업을 스스로 묻게됩니다. 테스트 작성은 구현보다는 인터페이스에 중점을 둡니다 (항상 좋은 것임). 또한 테스트가 진행될 때 코딩이 완료된 지점이 명확하다는 것을 의미합니다.
나는 현재 테스트 중심 개발을 옹호하는 사람이지만, 거의 5 년 전에이 책을 처음 읽었을 때이 개념에 대해 소개 한 것을 기억하지 못했습니다.
Amazon.com에 따르면이 책은 원래 1999 년 7 월 8 일에 출판되었습니다.이 책은 테스트 우선 프로그래밍에 대한 최초의 발행 본입니까?
답변
테스트 중심 개발은 사전 조건, 불변 및 사후 조건이있는 계약 별 디자인과 유사합니다.
이 용어는 에펠 프로그래밍 언어의 디자인과 관련하여 Bertrand Meyer에 의해 만들어졌으며 1986 년에 시작된 다양한 기사에서 처음으로 설명되었습니다 [Wikipedia]
공식적인 방법은 1983 년부터 시작되었으며 B- 방법을 사용하는 무인 파리 지하철과 같은 안전에 중요한 시스템에 사용되었습니다.
Abstract Machine이라는 첫 번째 및 가장 추상적 인 버전에서 디자이너는 디자인 목표를 지정해야합니다. [위키 백과]
켄트 벡은 “테스트 우선 프로그래밍의 재발견”을 개척하는 데 도움을 준 것들 중 일부일 수 있습니다.
요컨대 Nasa의 1960 년대 초 프로젝트 Mercury는 테스트 중심 개발 및 기타 민첩한 관행을 사용한 최초의 소프트웨어 프로젝트였습니다. 초기 문서를 찾을 수 없지만 다음 은 프로젝트 멤버의 커뮤니케이션을 인용 한 2003 보고서 입니다.
프로젝트 머큐리는 매우 짧은 (반나절) 반복 시간을두고 실행되었습니다. 개발 팀은 모든 변경 사항에 대한 기술적 인 검토를 수행했으며 흥미롭게도 각 마이크로 증분 전에 테스트 우선 개발, 계획 및 작성에 대한 익스트림 프로그래밍 실습을 적용했습니다.
보고서의 나머지 부분도 흥미 롭습니다.
반복 개발을 설명하고 권장하는 데 특히 초점을 맞춘 최초의 참조는 IBM TJ Watson Research의 Brian Randell과 FW Zurcher의 1968 년 보고서였습니다.
자동화 테스트 외에도 1968 보고서 는 테스트 우선이 아닌 경우 병렬 코딩 및 테스트를 옹호합니다.
지. 각 프로그램 블록의 세부 설계, 코딩 및 문서화
h. 단계 (g)와 동시에 각 프로그램 블록에 대한 테스트 방법의 설계 및 문서화.
답변
Programming Pearls의 Jon Bently (1986 년에 출판)는 특별히 Test-First 프로그래밍을 언급하지 않습니다. 그러나 “올바른 프로그램 작성”장에서는 먼저 전제 조건, 변형 및 사후 조건을 정의하여 알고리즘 작성에 대해 설명하고 다음 장에서는 자동 테스트 프레임 워크에 대해 설명합니다.
테스트 우선 순위는 아니지만 몇 가지 토대를 마련하고있었습니다.
또한,
CIO Magazine, 1993 년 3 월, Bug Busters , Lucie Juneau, pg 84 :
테스트 사례 … 코드를 작성하기 전에 개발할 수 있습니다. 이상적으로 이러한 사례는 응용 프로그램의 요구 사항을 기반으로합니다. 개발자가 코드 작성을 시작하기 전에 요구 사항 기반 테스트를 받으면 해당 테스트를 통과 할 수있는 제품을 설계하게됩니다 … “
