많은 사람들이 패치를 제출하기를 희망하고 기대하는 오픈 소스 프로젝트를 시작하고 싶다고 가정 해 봅시다. 엄격한 TDD 접근 방식을 취할 수 있습니까? 공동 작업자가 패치를 제출할 때마다 품질 테스트를 작성할 것으로 기대 / 신뢰할 수 있습니까?
내가 생각한 한 가지는 개별 버그 보고서 및 기능 요청에 대한 테스트 스위트를 작성하고 모든 패치 / 풀 요청이 테스트를 통과하도록 요구하는 것이지만 그 시점에서 기능 / 버그 수정을 작성하는 것이 더 좋을 것 같습니다 자기.
내가 알 수있는 한, TDD (또는 최소한 쓰기 테스트)를 사용하는 대부분의 주요 오픈 소스 프로젝트는 주로 개인이나 팀이 작성하는 것으로 보이며 TDD와 같은 관행을 시행하기 쉽습니다.
답변
일반인이 패치를 제출할 수있는 오픈 소스 프로젝트에서는 TDD (테스트 우선) 접근 방식을 실제로 시행 할 수 없습니다.
적용 할 수있는 것은 모든 패치에 패치에 포함 된 수정 프로그램에 대한 일련의 테스트 사례가 있어야하며 모든 기존 테스트 사례뿐만 아니라 해당 테스트 사례도 통과해야한다는 것입니다. 프로젝트 정책을 사용하고 동의하는 것으로 알려진 일부 신뢰할 수있는 개발자에게만 커밋 권한을 부여하고 제출 / 풀 요청이 테스트 사례가 통과 된 경우에만 통합됨을 공개적으로 명시함으로써이를 적용 할 수 있습니다. 충분한 범위).
이렇게하면 테스트가 먼저 작성 되지는 않지만 테스트가 작성 됩니다.
답변
사람들 이 코드 작업을하기 전에 테스트 전용 패치 를 제출하도록 요청할 수 있습니다. 이것은 코드 자체가 작성되기 전에 계획된 설계를 검토 할 수있는 추가 기회를 제공합니다.
실제로 이것은 프로젝트에 기여한 사람들의 열정을 없애거나 방법론에 동의하는 사람들에게 불을 붙일 수 있습니다.
그러나 검토자는 개발을 지연시키지 않기 위해 설계 검토를 빠르게 전환하는 데 매우 능숙해야합니다.