각각의 새로운 버그에 대한 단위 테스트 추가

내 직업에서 버그를 해결하는 모든 개발자는 이러한 유형의 버그에 대해 경고하는 새로운 단위 테스트를 추가해야합니다 (다시 문제가 발생하는 경우). 단위 테스트가 불가능한 경우 (예 : 웹 페이지 디자인 문제) QA 부서는 테스트 케이스를 작성하여 수동으로 확인해야합니다.

그 뒤에 아이디어는 제품 출시 전에 결함이 감지되지 않은 경우 결함을 감지하기위한 적절한 단위 테스트가 없기 때문에 발생한다는 것입니다. 따라서 개발자가 추가해야합니다.

문제는 소프트웨어 개발 방법론에서 일반적입니까? 이 기술은 이름이 있습니까? 그것에 대해 더 배우고 싶지만 시작하기 위해 정보가 필요합니다.

이것은 매우 일반적입니다. 우리는 이것을 우리 팀에서 사용합니다. 모든 생산 결함에 대해 개발자는 문제의 근본 원인에 대한 메모를 추가하고, 실패한 단위 테스트 를 추가하고, 코드를 체크인하기 위해 티켓을 dev 상태로 푸시하기 전에 테스트 영향 분석을 추가해야합니다.

실패한 단위 테스트는 코드를 프로덕션으로 푸시하기 전에 통과해야합니다.

나는 이것이 일반적인 "회귀 테스트"를 제외하고 특정 이름을 가지고 있다고 생각하지 않습니다. 이는 매우 유용하며이 프로세스를 시작한 후 제품 품질이 향상되는 것을 확인했습니다.

전혀!

단위 테스트가 좋은 것에 동의 할 수 있다면 버그가 있으면 해당 코드 경로를 다루는 누락 된 단위 테스트가 있다는 것을 알게 될 것입니다.

따라서 발생하는 것은 버그가 있음을 나타내는 단위 테스트를 작성하고 실제 버그를 수정 한 다음 단위 테스트를 통과하는 것입니다.

단위 테스트가 전혀없는 경우 프로젝트에 단위 테스트를 시작하는 것이 좋습니다.

이 기술은 테스트 중심 개발입니다. 반복 가능한 테스트 모음이 항상 도움이 되더라도 다음에 비슷한 버그를 발견 할 수는 없습니다. 요점은 코드에 문제가있는 것을 분리하고, 문제가 있음을 증명하고, 수정했으며, 수정이 올바른지 증명할 수 있다는 것입니다.

기억 나거나 찾을 수없는 인용문이 있지만, "모든 버그는 아직 작성되지 않은 테스트입니다."

IMHO, 회귀 테스트로 판매하려고 시도하는 것은 잃어버린 전투입니다. 이러한 버그가 반복적으로 발생하는 경우가 많으므로 대부분의 개발자는 "단순히 문제를 해결할 수있을 때 왜 귀찮게합니까?"라고 말합니다.

이 기술은 꽤 일반적이며 내 생각에 가장 좋은 이름은“결함 기반 테스트”입니다 (자신이 생각 해낸 다음 오래 전에이 이름으로 설명했습니다 ).

때때로 어떤 사람들은이 테스트를“회귀 테스트”라고 부르는 것을 볼 수도 있지만 개인적으로이 이름을 정당화하기는 다소 어렵다는 것을 알게되었습니다. “회귀 테스트”에 대한 다소 광범위하게 정의 된 용어 (그리고이 이름에 훨씬 더 의미가있는 정의)는“회귀가 발생하지 않도록 코드를 변경 한 후 테스트를 실행하는 것”과 CI 리포지토리에 푸시 할 때 각 분기를 테스트하여이를 충족시킵니다.