git로 자동 디버깅
복잡한 소프트웨어에서 더 큰 기능을 개발하고 있다고 상상해 보세요.구현이 완료되었습니다. 범위 내의 모든 테스트가 녹색으로 바뀌었습니다. 변경 사항을 통합 테스트로 전송합니다.그리고 완전히 다른 모듈에서 온 통합 테스트가 실패했습니다. 어떤 변경이 이 이 점을 초래했는지 알 수 없습니다.이제 너는 이 문제를 분석하기 시작해라.손으로 당신의 제출을 탐색하면 틀림없이 매우 지루한 과정으로 끝날 것이다.고맙습니다.git는 모든 일을 도와줄 수 있고, 커피 한 잔을 즐길 수 있습니다.
고급 명령
git bisect을 사용하면 지정한 테스트 과정을 자동으로 실행할 수 있으며, 제출 기록에서 잘못된 수정을 찾을 수 있습니다.요구 사항
작업을 수행하려면 로컬 시스템에서 다음 설정을 수행해야 합니다.
git 대분은 무엇입니까?
git-bisect documentation의 공식 설명:
바이너리 검색을 사용하여 잘못된 제출을 찾습니다.
그게 무슨 뜻이에요?
만약 네가 한 무더기의 제출을 가지고 있다면, 너는 알다시피, 어느 때, 너의 소프트웨어는 그런대로 괜찮다.현재, 당신의 소프트웨어가 고장났다는 것은 당신이 개발 과정에서 버그를 도입했다는 것을 의미한다.
git bisect 바이너리 검색을 통해 선택한 특정 제출을 테스트하여 수정도를 좋은 부분과 나쁜 부분으로 나누는 것이다.테스트 결과를 바탕으로git 내비게이션이 전송을 중단합니다.몇 차례의 교체를 거친 후에git는 이 문제를 도입한 버전을 식별할 수 있을 것이다.기본git 분할 작업 흐름
git bisect의 작업 절차는 두 가지 주요 절차를 포함한다.우선, 좋은 수정과 나쁜 수정의 제한을 받는 수정 범위를 지정해야 합니다.이 수정들은 수정 해시, 표기 또는 다른git 수정 선택기로 인용할 수 있다.두 번째 단계는 분할 과정을 시작하고git는 첫 번째 버전의 서명을 자동으로 실행하여 테스트를 진행한다.테스트 결과를git로 전달한 후 성공하면 실행git bisect good, 실패하면 실행git bisect bad, 다음 버전을 선택합니다.첫 번째 손상된 버전을 찾을 때까지 두 번째 단계를 반복합니다.
수동git 분할
현재, 당신은 이미 생각과 업무 절차를 이해했으니, 우리들은 계속 착수합시다.먼저 예시 항목을 포함하는 repository from GitHub 을 검사합니다.보시다시피 저장소에는 다음과 같은 세 개의 폴더가 있습니다.
mvn -f ./cake-factory/pom.xml clean install
통합 테스트 실패Citrus로 인해 구축이 성공하지 못했다는 것을 알게 될 것입니다.이제 우리가 어디에서 이 버그를 도입했는지 봅시다.
작업 흐름과 같이 우리는 먼저 대분 장면을 설정해야 한다.따라서 우리는 분석의 경계를 정의하기 위해 좋은 것과 나쁜 수정을 찾아야 한다.이 두 판본은 모두 쉽게 찾을 수 있다.좋은 버전은 아마도 너의 분기 버전일 것이다.엉망진창인 수정은 긍정적이다. 왜냐하면 너의 테스트가 지금 실패했기 때문이다.그러나 우리의 예시에서 우리는 두 개의 준비된 라벨을 사용할 것이다. 그것은 안정적이고 저장소에서 분리된 것이다.
git bisect start # start the bisect procedure
git bisect bad broken # label the *bad* commit
git bisect good stable # label the *good* commit
git bisect start broken stable # start the procedure and label the *good* and *bad* commit
지금까지 문제의 근원을 확인하기 위한 테스트 전략을 찾았을 것입니다.우리의 사례에서 통합 테스트가 실패했다.따라서 우리는 디버깅 작업을 통합 테스트에 집중할 것이다.케이크 공장의 설정은 단원 테스트를 건너뛰고 속성 설정
skip.unit.test=true을 통해 즉시 통합 테스트를 시작할 수 있도록 합니다.mvn clean verify -f ./cake-factory/pom.xml -Dskip.unit.tests=true
이번 수정에서 모든 것이 정상적이고 구축에 성공했다.지금 우리는git에게 이 결과를 보고해야 한다
git bisect good # tells git that the current revision is okay
#If the test would have been failed, you would have used 'git bisect bad'
지금 너는 반드시 테스트와 보고 프로그램을 중복해야 한다.몇 가지 교체를 거친 후, 당신은 아래의 제출이 문제를 초래했다는 것을 발견할 수 있습니다.
제출된 수정 해시를 중단하고 대분 세션을 닫는 것을 잊지 마십시오.
git bisect reset
자동git 분할
이미 알고 있는 바와 같이, 수동으로 실행하는 것은 단계별로 갑자기 비용이 발생하고, 중복적인 임무이다.만약 네가 여러 모듈과 관련된 더 복잡한 프로젝트에서 일한다면, 이것은 증가할 것이다.고맙게도
git bisect 는 하위 명령을 포함하여 특정 명령이나 스크립트 테스트 과정을 실행하고 결과를 자동으로 보고할 수 있습니다.이것은 소요되는 시간을 줄일 뿐만 아니라 수동으로 단계를 반복할 때 오류가 발생할 가능성도 감소시킨다.git bisect run <command to execute>
테스트가 성공하면 실행된 명령은 코드 0을 되돌려줍니다. 그렇지 않으면 0을 제외한 코드를 되돌려줍니다.
이 계약만 이행하면python, 심지어java를 사용하여 더 높은 테스트 논리를 실행할 수 있습니다.그럼에도 불구하고 저는 여러분들이 실용적으로 테스트를 간단하게 유지하는 것을 건의합니다.
인스턴스
우리 실천으로 돌아가자.이전 섹션에서 완료되지 않은 경우 예제 항목을 포함하는 repository from GitHub 을 체크 아웃합니다.자동 분할 폴더에서 findBug를 찾을 수 있습니다.shbash 스크립트, "수동git 대분"부분의 테스트 프로세스 코드를 포함합니다.
#!/bin/bash
mvn clean verify -f ./cake-factory/pom.xml -Dskip.unit.tests=true
git bisect run 전달하면 됩니다.git bisect start broken stable
git bisect run sh automated-bisect/findBug.sh
git bisect run에 직접 전달할 수 있습니다. 전달된 명령이 약속을 충족시키기만 하면 됩니다.git bisect start broken stable
git bisect run mvn clean verify -f ./cake-factory/pom.xml -Dskip.unit.tests=true
제시와 기교
git 분할 및 TDD 정보
만약 TDD의 생명주기에 따라 소프트웨어를 개발한다면, git를 사용하여 구분하는 데 문제가 있을 수 있습니다. 소프트웨어 테스트의 측면에서 볼 때, 소프트웨어가 오류 상태와 기능 상태 사이를 교체하기 때문입니다.새로운 테스트를 지정하면 소프트웨어가 불안정해진다.이런 상황에서 간단한
mvn clean install 을 실행하면 git bisect 문제의 근원을 포함하는 수정을 찾을 수 없습니다. 왜냐하면 TDD 테스트로 인한 실패 생성에 헷갈리기 때문입니다.마븐 명령에서 삭제skip.unit.tests=true를 통해 우리 케이크 공장의 예시도 이 점을 나타낼 수 있다.git bisect start broken stable
git bisect run mvn clean verify -f ./cake-factory/pom.xml
git bisect는 모든 실패한 단원 테스트에 반응할 것이다.이것도 결과를 초래할 수 있지만, 이것은 우리가 찾는 문제의 근본적인 원인과 무관하다.
현명하게 테스트 장면을 설정하다
"git 대분과 TDD에 관하여"절에서 보듯이 제한성이 부족한 테스트 장면은 오도적인 결과를 되돌려줍니다.따라서 당신의 상황에 맞는 테스트 장면을 만드는 것이 매우 중요합니다.다음은 함정을 피하는 데 도움을 줄 수 있는 몇 가지 요점입니다.
테스트 규모 최소화
문제와 직접 관련된 필요한 내용만 테스트한다.이것은 정확한 결과를 낳고 테스트 운행 시간을 줄일 것이다.
의존 관계 이해
만약 실패한 테스트가 개발 과정에서 변경된 다른 모듈에 의존한다면, 테스트를 시작하기 전에, 매번 교체될 때마다 의존 관계를 재구성해야 한다는 것을 기억하십시오.
자동화 테스트
만약 네가 한 번이 아니라면, 그것들을 자동화해라!수동으로 테스트를 실행하지 마세요.이것은 많은 시간을 소모하는 중복적인 임무이다.테스트 스크립트를 작성하고
git bisect run 남은 작업을 완성합니다.흔한'나쁨'과'좋음'후보자를 사용하다
가장 효과적인 경계 분석에 시간을 낭비하지 마라.
git bisect run이 당신을 위해 이 일을 완성할 것이기 때문에, 한 번의 교체는 많든 적든 중요하지 않습니다.엉망진창인 후보: 주로 머리
우수 후보:
총결산
보시다시피,git 대분은 강력한 도구입니다.git 역사에서 중단된 제출을 찾을 수 있습니다.자동으로 검사될 일련의 개정을 정의할 수 있습니다.git 대분에 대한 더 많은 정보를 알고 싶으면 다음 링크를 방문하십시오.
Reference
이 문제에 관하여(git로 자동 디버깅), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/svettwer/automated-debugging-with-git-2pod텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
좋은 웹페이지 즐겨찾기
