협업 오픈 소스 프로젝트에서 TDD를 실행할 수 있습니까?

많은 사람들이 패치를 제출하기를 희망하고 기대하는 오픈 소스 프로젝트를 시작하고 싶다고 가정 해 봅시다. 엄격한 TDD 접근 방식을 취할 수 있습니까? 공동 작업자가 패치를 제출할 때마다 품질 테스트를 작성할 것으로 기대 / 신뢰할 수 있습니까?

내가 생각한 한 가지는 개별 버그 보고서 및 기능 요청에 대한 테스트 스위트를 작성하고 모든 패치 / 풀 요청이 테스트를 통과하도록 요구하는 것이지만 그 시점에서 기능 / 버그 수정을 작성하는 것이 더 좋을 것 같습니다 자기.

내가 알 수있는 한, TDD (또는 최소한 쓰기 테스트)를 사용하는 대부분의 주요 오픈 소스 프로젝트는 주로 개인이나 팀이 작성하는 것으로 보이며 TDD와 같은 관행을 시행하기 쉽습니다.

open-source tdd collaboration

— DormoTheNord
소스

연구 결과를 공유하면 모든 사람에게 도움이됩니다. 당신이 무엇을 시도했고 왜 그것이 당신의 요구를 충족시키지 못했는지 알려주십시오. 이것은 당신이 시간을내어 자신을 돕기 위해 노력했고, 명백한 답변을 반복하지 못하게하며, 무엇보다도보다 구체적이고 관련성있는 답변을 얻는 데 도움이됩니다. 또한 물어

— gnat

@gnat StackExchange를 검색했는데 사람들이 단위 테스트를 사용하여 오픈 소스 프로젝트의 예를 묻는 몇 가지 질문이 있습니다. 이는 내 질문과 다릅니다. 귀하의 요청에 따라 더 많은 정보를 추가했습니다.

— DormoTheNord

DormoTheNord @gnat은 구체적이고 인용 된 예를 의미한다고 생각 합니다.

— haneefmubarak

"기능 / 버그 픽스를 직접 작성하는 것이 좋습니다." 테스트 유무에 관계없이? 당신은 TDD 지지자입니까, 아니면이 맥락에서 그것이 가능한지 확인하고 있습니까?

— JeffO

물론 공동 작업자가 패치를 제출할 때마다 품질 테스트를 작성할 수 있습니다. 그것은 유익 할뿐만 아니라 오늘날 대규모 오픈 소스 프로젝트에서 매우 일반적입니다 (원하는 경우 예를들 수 있습니다).

— Benjamin Gruenbaum

답변:

일반인이 패치를 제출할 수있는 오픈 소스 프로젝트에서는 TDD (테스트 우선) 접근 방식을 실제로 시행 할 수 없습니다.

적용 할 수있는 것은 모든 패치에 패치에 포함 된 수정 프로그램에 대한 일련의 테스트 사례가 있어야하며 모든 기존 테스트 사례뿐만 아니라 해당 테스트 사례도 통과해야한다는 것입니다. 프로젝트 정책을 사용하고 동의하는 것으로 알려진 일부 신뢰할 수있는 개발자에게만 커밋 권한을 부여하고 제출 / 풀 요청이 테스트 사례가 통과 된 경우에만 통합됨을 공개적으로 명시함으로써이를 적용 할 수 있습니다. 충분한 범위).

이렇게하면 테스트가 먼저 작성 되지는 않지만 테스트가 작성 됩니다.

— 바트 반 인겐시나 우
소스

확실히 리포지토리 소유자는 프로젝트의 품질 표준을 준수하지 않는 변경 사항을 가져 오기를 거부 할 수 있습니까? 기고자들이 이것을 싫어하면 기여의 질과 양이 어려울 수 있지만, 그렇게 할 수는 없습니다 . 확실히?

— Tom W

@TomW : 구현이 완료된 후 작성된 테스트가 아닌 TDD 사례에 따라 제출물이 작성되었는지 어떻게 확인 하시겠습니까?

— Bart van Ingen Schenau

아 무슨 말인지 알 겠어 나는 엄격한 손실이 불가피하다고 생각하지만, 코드가 테스트와 함께 제공되는지, 테스트가 충분히 세분화되어 있고 필요한 모든 것을 포함하는지 확인할 수 있습니다. 나는 git에 익숙하지 않지만 주어진 풀 요청에 대해 해당 변경 세트에 대한 커밋 시퀀스를 검사하여 개발자가 적절한 프로세스를 수행하여 생성했는지 확인할 수 있습니까?

— Tom W

즉, 내부 프로세스를 확인할 수는 없지만 출력이 특정 표준을 충족하는지 확인할 수 있습니다. 테스트가 필요하고 디자인이 논리적인지 확인하는 것은 소유자의 힘 안에 있습니다.

— Adrian Schneider

사람들 이 코드 작업을하기 전에 테스트 전용 패치 를 제출하도록 요청할 수 있습니다. 이것은 코드 자체가 작성되기 전에 계획된 설계를 검토 할 수있는 추가 기회를 제공합니다.

실제로 이것은 프로젝트에 기여한 사람들의 열정을 없애거나 방법론에 동의하는 사람들에게 불을 붙일 수 있습니다.

그러나 검토자는 개발을 지연시키지 않기 위해 설계 검토를 빠르게 전환하는 데 매우 능숙해야합니다.

— 알렉스 페이 먼
소스