버그를 수정할 때 항상 단위 테스트 버그를해야합니까?


29

버그를 수정할 때 주어진 버그로 실패한 테스트를 먼저 작성하고 테스트가 통과 할 때까지 코드를 수정하는 것이 좋습니다. 이것은 TDD 관행을 따르고 모범 사례로 생각되지만 실제로 구현에 가까운 암호 테스트를 생성하는 경향이 있음을 알았습니다.

예를 들어, 직업이 전송되고 특정 상태에 도달하여 중단되고 재 시도 될 때 문제가 발생했습니다. 이 버그를 재현하기 위해 스레드 동기화, 많은 조롱 및 물건으로 대규모 테스트가 작성되었습니다. 작업을 수행했지만 코드를 리팩토링하고 있으므로이 매머드를 제거하는 것이 매우 유혹적입니다. 새로운 디자인에 맞추려면 많은 작업이 필요합니다. 그리고 하나의 특정 사례에서 하나의 작은 기능 만 테스트합니다.

따라서 내 질문 : 재현하기 까다로운 버그를 어떻게 테스트합니까? 구현을 테스트하고 리팩토링과 가독성을 떨어 뜨리는 것을 피하는 방법은 무엇입니까?


오류 사례가 새로운 디자인과 관련이 있습니까? 새로운 디자인의 일부는 디자인의 신뢰성을 높이는 것이기 때문에 이러한 유형의 버그가 원래 디자인의 실수와 관련이 있다면이 테스트 사례를 제거하는 것을 정당화하는 데 사용할 수 있습니다.
Thymine

리 팩터는 다른 것에 관한 것이므로 새로운 디자인에서 코드를 약간 수정하고 버그를 다시 소개하는 것이 가능합니다. 테스트에 대한 대안은 "이것과 섹스하지 말아라"는 코드의 주석 일 것 같지만, 잘못된 행동 인 것 같습니다 : p
Zonko

1
그것이 unittest를 위해 너무 복잡하다면 그것을 통합 테스트의 일부로 만드십시오
ratchet freak

이와 같은 소리는 단위 테스트가 아니라 통합 테스트가 필요합니다. 당신이 너무 조롱한다는 사실에 근거합니다. 내가 본 일반적인 규칙은 코드베이스 외부의 구성 요소 (데이터베이스와 대화, 파일 시스템에서 읽는 등)와 대화하는 코드는 테스트하지 않는 것입니다.
Lucas

답변:


27

예, 일반적으로해야 합니다 . 모든 지침과 마찬가지로 다른 지침에 반할 때 최선의 판단을해야합니다. 이 시나리오에서는 버그를 심각하게 평가하여 비즈니스 문제를 목표로하고 버그 상태의 회귀를 잡기 위해 테스트 및 테스트 품질을 구현하는 데 필요한 작업과 비교해야합니다.

버그를 중단시키는 중단이 단순히 단위 테스트를 개발하고 유지하는 것보다 더 많은 오버 헤드를 갖는 경향이 있기 때문에 테스트 작성을 선호하지 않습니다.


나는 이것에 더 중점을두고 이상적인 세계에서는 실패한 단위 테스트가 존재하는 경우에만 버그로 간주되지만 이탤릭체에 +1하고 비즈니스 요구 우선 한다는 점을 지적 합니다.
Joshua Drake

2
글쎄, 결국, 테스트를 유지하는 데 필요한 시간과 멍청한 놈이 다시 발생하면 벌레를 감지하고 수정하는 데 걸리는 시간 사이의 균형에 관한 것입니다.
Zonko

또한 테스트를 일반화하여 특정 특정 상태에 도달했을 때 작업 중단 및 재 시도를 테스트하는 것이 아니라 작업이있을 수있는 모든 상태에서 중단 및 재 시도를 테스트하는 것이 좋습니다.
Old Pro

"버그를 중단시키는 중단 때문에 단순히 단위 테스트를 개발하고 유지하는 것보다 더 많은 오버 헤드가있는 경향이 있습니다."
피터 K.

16

나는 종종 따르지 않는 것을 인정하는 것이 당혹 스럽지만 모범 사례는 생산 과정에서 관찰 된 문제를 보여주는 시스템 또는 통합 테스트를 만든 다음 문제의 원인이되는 장치를 찾기 위해 연구하는 것입니다. 그런 다음 장치 수준에서 문제를 나타내는 장치에 대한 장치 테스트를 작성하십시오 . 단위 테스트가 완료되면 단위를 수정하고 모든 테스트를 실행하십시오. 이 시점에서, 원래의 테스트는 깨지기 쉽고 느리기 때문에 원래 테스트를 폐기하는 것이 현명 할 수 있지만 회귀 및 적용을 위해 자동화 된 스위트에서 단위 테스트를 유지하십시오.


7

결함을 식별하기 위해 테스트를 작성하는 방법은 결함을 재현하고 수정되었는지 확인하는 데 필요한 단계를 정확하게 식별 할 수 있기 때문에 좋은 아이디어입니다. 또한 이러한 테스트는 연기 테스트 또는 회귀 테스트의 일부로 실행되어 이후 변경으로 인해 시스템에 오래된 결함이 다시 도입되지 않도록 할 수 있습니다.

가장 먼저 고려해야 할 것은 필요한 테스트 수준입니다. 수정 사항을 검증하기위한 테스트가 시스템 레벨에서 더 적합하거나 수동으로 수행되는 승인 테스트 일 수도 있습니다. 구체적으로 구현 된 방식에 관계없이 문서화되고 관리되는 테스트를하는 것이 더 중요하다고 생각합니다.

리팩토링이 테스트에 미치는 영향은 특정 ​​특성에 따라 다릅니다. 경우에 따라 리팩토링 (또는 새로운 기능과 같은 모든 유형의 작업)으로 인해 테스트가 더 이상 필요하지 않을 수 있습니다. 원래 발생한 문제는 더 이상 가능하지 않을 수 있습니다. 이 경우 가능한 테스트에서 테스트를 제거하여 테스트 프로세스 (자동 또는 수동)를보다 간결하게 만드는 것이 좋습니다. 다른 경우에는 여러 가지 방법으로 테스트를 수행하고 다른 수준에서 기능을 확인하는 것이 더 적절할 수 있습니다. 기능이 사소한 경우 테스트가 더 이상 필요하지 않을 수 있습니다.

테스트에 의존 할뿐만 아니라 로깅도 고려할 수 있습니다. 예를 들어, 런타임에 정보를 캡처 (환경에 따라 다양한 레벨로 표시-테스트 중 더 자세한 정보, 배포 중에 덜 자세한 정보 표시), 응용 프로그램 프로파일 링, 시스템의 현재 상태 덤프를 캡처합니다. 문제에 대한 일반적인 트리거를 찾을 수 있으면이를 사용하여 모든 수준에서 테스트를 안내 할 수 있습니다.


5

그렇습니다.

기존 코드베이스에 대한 단위 테스트를 작성하십시오. 버그를 수정할 때 단위 테스트에 실패했는지 확인해야합니다. 이렇게하면 실제로 버그를 처리하고 있다는 확신을 갖게됩니다. 그런 다음 버그를 수정하여 리팩터링하고 테스트를 통과해야합니다.

그러나 이것은 TDD 연습이 아닙니다. TDD 테스트에서는 설계를 주도하지만 귀하의 경우 설계가 이미 결정되었습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.