TDD 및 버전 관리

저는 현재 TDD에 대해 배우고 있으며 개인 프로젝트에 적용하려고합니다. 또한 이러한 많은 프로젝트에서 버전 제어를 광범위하게 사용했습니다. 나는 커밋을 작게 유지하는 것이 최대 일 때 전형적인 작업 흐름 에서이 두 도구의 상호 작용에 관심이 있습니다. 다음은 몇 가지 예입니다.

1. 새 프로젝트를 시작하고 아직 존재하지 않는 클래스를 만들기위한 간단한 테스트를 작성합니다. 테스트가 컴파일되지 않더라도 클래스를 작성하기 전에 테스트를 커밋해야합니까? 아니면 커밋하기 전에 테스트를 컴파일하는 데 필요한 최소량의 코드를 스텁해야합니까?

2. 버그를 찾아서 다시 작성하기위한 테스트를 작성합니다. 실패한 테스트를 커밋하거나 버그 수정을 구현 한 다음 커밋해야합니까?

이들은 바로 떠오르는 두 가지 예입니다. 답변에 추가 예를 자유롭게 제공하십시오.

편집하다:

두 예제 모두에서 테스트를 작성한 직후 테스트를 통과하는 코드를 작성한다고 가정했습니다. 또 다른 상황이 발생할 수도 있습니다. 나는 커밋하지 않고 몇 시간 동안 TDD를 사용하여 프로젝트를 진행합니다. 마지막으로 커밋 할 때 작업을 작은 덩어리로 나누고 싶습니다. (Git은 단일 파일에서 일부 변경 사항 만 커밋하려는 경우에도 비교적 쉽게 만듭니다.)

이것은 내 질문이 커밋 할 때만 큼 커밋 할 것에 관한 것임을 의미합니다 .

테스트가 컴파일되지 않더라도 클래스를 작성하기 전에 테스트를 커밋해야합니까? 아니면 커밋하기 전에 테스트를 컴파일하는 데 필요한 최소량의 코드를 스텁해야합니까?

당연히 아니지. 시험과 수업을 모두 마쳐야합니다. 컴파일조차하지 않는 ¹ 을 커밋 하는 것은 의미가 없으며 정기적으로 같은 프로젝트를 수행하는 사람들을 화나게 할 것입니다.

버그를 찾아서 다시 작성하기위한 테스트를 작성합니다. 실패한 테스트를 커밋하거나 버그 수정을 구현 한 다음 커밋해야합니까?

아니오, 테스트 실패를 저 지르지 마십시오. 르블랑의 법칙 상태 :

나중에 결코 같지 않습니다.

테스트가 오랫동안 실패 할 수 있습니다. 문제가 감지되는 즉시 해결하는 것이 좋습니다.

또한 TDD 개발 스타일 은 다음을 알려줍니다.

테스트 중심 개발은 실패한 테스트 사례를 추가, 전달 및 리팩토링하는 단계를 지속적으로 반복합니다.

실패한 테스트를 확인하면주기가 완료되지 않았 음을 의미합니다.

¹ 커밋을 말했을 때, 실제로 트렁크에 커밋한다는 것을 의미했습니다 (git 사용자의 경우 변경 사항을 푸시하면 다른 개발자가 얻을 수 있습니다).

테스트가 컴파일되지 않더라도 클래스를 작성하기 전에 테스트를 커밋해야합니까?

아니.

실패한 테스트를 커밋해야합니까

아니.

여기서 두 가지 패러다임에 대해 이야기하고 있습니다.

1. 테스트 주도 개발-코드 커밋에 대해 아무 말도하지 않습니다. 실제로 코드 작성 방법과 완료시기에 대해 알려줍니다. 그래서 나는 모든 '완료'를 커밋의 후보로 생각합니다.
2. 민첩한 개발, 특히 : "초기 및 빈번한 커밋"(TDD 필요 없음) 그 배후의 아이디어는 시스템의 다른 구성 요소와 조기 통합하여 조기 피드백을 얻는 것입니다. DVCS를 로컬로 커밋하고 푸시하지 않으면 그 의미에서 가치가 없습니다. 로컬 커밋은 개발자가 업무를 구조화하는 데 도움이됩니다.

내 권장 사항은 : 코드가 컴파일되고 테스트가 녹색이며 시스템에 기여할 무언가가 생길 때까지 TDD 서클을 따르십시오. 따라서 새로운 UI 마스크의 경우 기능을 세로로 잘라 비즈니스 로직없이 전체 양식을 작성하지 않고 커밋하지 말고 하나의 작은 측면을 구현하지만 프론트 엔드 및 비즈니스 로직 및 지속성 계층을 구현하십시오. .

큰 버그 수정의 경우, 버그가 아직 수정되지 않은 경우에도 각 개선 (예 : 리팩토링) 후에 커밋합니다. 테스트는 녹색이어야하고 코드는 컴파일되어야합니다.

확실히 당신은 git과 같은 건강한 소스 컨트롤을 사용하는 것으로 시작합니다.

그런 다음 원하는 방식으로 작업하고 각 코너에서 커밋 할 수 있습니다. 모든 단계 또는 하위 단계는 공정한 게임입니다.

그런 다음 물건을 밀기 전에 전체 작업을 단일 커밋으로 스쿼시하십시오. 또는 모든 것이 녹색이고 구성이 의미가있는 지점에서 몇. 그리고 현명한 커밋을 추진하십시오. 여러 경우에 대해 --no-ff와 병합하는 분기로 만듭니다.

소스 컨트롤은 작업 추적 시스템이나 역사가가 아닙니다. 커밋은 적절한 코 히어 런트 델타를 제공하는 반면, 체크 아웃 상태는 최소한 컴파일됩니다. 중간체는 검토 목적으로 잠시 동안 보존 될 수 있지만 일단 모든 것이 정상으로 간주되면 기능 당 단일 커밋이 공정합니다.

세상에 대한 나의 이해는 돌아 오는 것이 바람직 할 수있는 요점을 표시하는 것입니다. 테스트가 실패하는 지점 (하지만 컴파일)은 분명히 그러한 지점 중 하나입니다. 테스트 패스를 만들려고 잘못된 방향으로 방황하고 싶다면 코드를 다시 시작점으로 되돌리고 다시 시도하고 싶습니다. 커밋하지 않으면이 작업을 수행 할 수 없습니다.

테스트가 컴파일되지 않더라도 클래스를 작성하기 전에 테스트를 커밋해야합니까?

분기 SCM (Git을 사용하는 것을 보았습니다)을 사용하면 백업 지점을 원할 때마다 ( "나는 무언가를 망쳤습니다. 작업 디렉토리를 마지막 백업 지점으로 재설정합니다") 안정적인 버전이있을 때 커밋해야합니다. 안정적인 버전 (모든 테스트 통과)이있는 경우 현재 기능 분기를 기본 개발 분기에 병합하는 것도 고려해야합니다.

아니면 커밋하기 전에 테스트를 컴파일하는 데 필요한 최소량의 코드를 스텁해야합니까?

귀하에게 달려 있습니다 (git은 팀의 다른 구성원에게 영향을 미치지 않거나 다른 기능에 대한 작업 능력에 영향을주지 않고 언제든지 커밋 할 수있는 유연성을 제공합니다). 동일한 지점에 동시에 여러 개의 불완전한 (작동하지 않는) 기능이 없는지 확인하십시오 (그러면 서로 차단됩니다).

버그를 찾아서 다시 작성하기위한 테스트를 작성합니다. 실패한 테스트를 커밋하거나 버그 수정을 구현 한 다음 커밋해야합니까?

테스트 코드가 실제로 작거나 사소한 경우가 아니라면 일반적으로 두 가지 커밋을 수행합니다.

이들은 바로 떠오르는 두 가지 예입니다. 답변에 추가 예를 자유롭게 제공하십시오.

편집하다:

두 예제 모두에서 테스트를 작성한 직후 테스트를 통과하는 코드를 작성한다고 가정했습니다.

그것은 잘못된 가정 일 수 있습니다. 혼자서 (개인 프로젝트) 일한다고해서 항상 그렇게하는 것을 막을 수있는 것은 없습니다. 프로젝트 개발 전반에 걸쳐 높은 코드 품질과 TDD 유지와 관련하여 가장 성공적인 프로젝트 중 하나에서 테스트를 구현하기 몇 주 전에 테스트를 정의했습니다. 즉 "test_FOO_with_null_first_parameter"테스트는 이제 빈 함수로 정의되고 그런 다음 모듈의 테스트 범위를 늘리기 위해 한 달 정도 후에 스프린트 (또는 스프린트 반)를 수행 할 것입니다.

또 다른 상황이 발생할 수도 있습니다. 나는 커밋하지 않고 몇 시간 동안 TDD를 사용하여 프로젝트를 진행합니다. 마지막으로 커밋 할 때 작업을 작은 덩어리로 나누고 싶습니다. (Git은 단일 파일에서 변경 사항 중 일부만 커밋하려는 경우에도 비교적 쉽게 수행 할 수 있습니다.) 이것은 내 질문이 커밋 시점과 커밋 대상에 관한 것임을 의미합니다.

나는 확실히 백업 지점을 만들 것을 약속합니다 . 이것은 탐색 적 테스트 ( "코드베이스 전체에 약간의 프린트를 추가하고, 실행이 git reset --hard완료되면 프린트 를 제거하는 것)와 프로토 타이핑에 매우 효과적입니다 .

내 작업 흐름에서 가능할 때마다 개인 소스 제어 부서에 대한 작업이 확실하지 않습니다. 따라서 시도, 실패, 작동 할 때까지 필요한 경우 다시 시도하고 실제 작업 코드가있을 때만 더 큰 프로젝트를 커밋 할 수 있습니다.

TDD 관점에서, "시험을 먼저 체크인합니까?" 작업중 인 코드에 전적으로 의존합니다. 새 코드 인 경우 체크인 할 가치가있을 때까지 체크인하지 않습니다. 그러나 이미 컴파일 또는 배송 된 코드에서 발견 된 버그 인 경우 버그를 재현하기위한 테스트를 확인하면 BYSELSELF가 체크인 할 가치가 있습니다. 특히 근무일이 끝나면 수정을하기 전에 사무실을 떠나야합니다. 코드.

(물론, 상점에 단위 테스트가 실패하면 죽는 자동화 된 빌드 프로세스가있는 경우 버그를 수정하기 전까지는 실패한 테스트를 확인하고 싶지 않을 수 있습니다. 그러나 "찾기 문서 버그 "및"수정 버그 "는 완전히 다른 두 팀이 수행 할 수 있습니다.)