계속 실패 등록을 해야 하나요?

Question

저는 제가 유지 관리하는 앱에 대한 자동화된 회귀 테스트 제품군을 작업 중입니다.자동화된 회귀 테스트를 개발하는 동안 거의 확실히 버그인 몇 가지 동작을 발견했습니다.그래서 지금은 실패를 등록하지 않도록 자동화된 회귀 테스트를 수정했습니다. 의도적으로 이 나쁜 동작이 지나가도록 허용한다는 의미입니다.

그래서 저는 이 사이트에 있는 다른 사람들의 의견에 관심이 있습니다.분명히 이 오류 동작이 수정되었는지 확인하기 위해 결함 추적에 버그를 추가할 것입니다.그러나 지속적으로 실패를 나타내도록 회귀 테스트를 변경하거나 결함 있는 동작을 수정할 수 있을 때까지 회귀 테스트를 중단하고 실패하지 않도록 해야 하는 설득력 있는 이유가 있습니까(어느 쪽이든)?나는 이것을 다른 유형의 질문 중 6/16이라고 생각하지만 다른 사람들이 다르게 볼 수도 있다고 생각하여 여기에 묻습니다.

---

@폴 톰블린,

분명히 말씀드리자면 저는 테스트 제거를 고려한 적이 없습니다.나는 테스트를 실행할 때마다 실패가 내 얼굴에 던져지지 않고 실패를 허용하도록 통과/실패 조건을 수정하는 것을 고려하고 있었습니다.

알려진 원인으로 인한 반복적인 실패가 결국 C++에서 경고처럼 처리되는 것에 대해 약간 걱정됩니다.나는 C++ 코드에서 경고를 보고 쓸모없는 소음이라고 생각하여 이를 무시하는 개발자를 알고 있습니다.회귀 분석 모음에 알려진 실패를 남겨두면 사람들이 다른, 어쩌면 더 중요한 실패를 무시하기 시작할 수도 있습니다.

그런데, 오해를 피하기 위해 저는 C++의 경고가 강력한 코드를 만드는 데 중요한 도움이 된다고 생각하지만, 제가 만난 다른 C++ 개발자들에 따르면 제가 소수에 속한다고 생각합니다.

Answer 1

나는 "그래요!"라고 말할 것입니다.간단한 사실은, 그것이 실패하고 있는가?예!그러면 기록되어야 합니다.실패한 테스트를 통과시켜 테스트를 상당히 손상시키는 것입니다.

개인적으로 걱정되는 한 가지는 이 작업을 수행하고 버스 밑으로 가면 "패치"가 제거되지 않을 수 있다는 것입니다. 즉, "버그 수정" 후에도 버그가 여전히 남아 있을 수 있다는 것입니다.

그대로 두고, 프로젝트 노트를 업데이트하고, 심각도를 낮출 수도 있습니다(가능한 경우). 하지만 손상된 항목을 확인하는 작업을 손상시키지 마세요. ;)

Answer 2

테스트를 중단하면 언제 수정되었는지 어떻게 알 수 있으며, 더 중요하게는 다시 손상되는지 어떻게 알 수 있습니까?나는 테스트를 다시 추가하는 것을 잊어버릴 가능성이 높기 때문에 테스트를 수행하는 것에 반대합니다.

Answer 3

단위 테스트에 '스누즈' 기능을 추가했습니다.이를 통해 기본적으로 '이 날짜로부터 X주 동안의 실패 무시'라는 속성으로 테스트에 주석을 달 수 있었습니다.개발자는 이를 통해 한동안 수정되지 않을 것으로 알고 있는 테스트에 주석을 달 수 있지만 나중에 수동으로 다시 활성화하기 위해 개입할 필요가 없으며 테스트는 지정된 시간에 테스트 모음으로 다시 팝업됩니다.

Answer 4

예상한 대로 작동하지 않으면 실패로 남아 있어야 합니다.

그렇지 않으면 무시하기가 너무 쉽습니다.일을 단순하게 유지하십시오 - 작동하거나 작동하지 않습니다.실패 또는 성공 :)

-- 케빈 페어차일드

Answer 5

나는 Paul이 말한 대부분에 동의하지만, 엄밀히 말하면 회귀 테스트는 오래된 버그뿐만 아니라 프로그램 동작의 변경 사항을 테스트해야 한다는 주장의 다른 측면도 있습니다.그들은 당신이 예전에 작동하던 것을 망가뜨렸을 때 당신에게 구체적으로 알려 주기로 되어 있습니다.

나는 이것이 이 앱에서 실행되는 다른 종류의 테스트로 귀결된다고 생각합니다.일종의 단위 테스트 시스템이 있는 경우 회귀 테스트(적어도 버그가 수정될 때까지)보다는 이 테스트에 더 적합한 장소일 수 있습니다.그러나 회귀 테스트가 유일한 테스트라면 아마도 테스트를 그대로 두겠습니다.

Answer 6

버그가 있으면 테스트가 실패하는 것이 가장 좋지만 이는 종종 비현실적인 선택입니다.영역에 처음으로 테스트를 추가할 때 발견한 버그에 빠져 주요 목표를 완료하지 못하는 것이 특히 쉽습니다.또한 오랫동안 실패한 테스트는 너무 많은 잡음이 되어 무시하기 쉽고 쉬워집니다.

실패한 테스트를 작성하는 것은 버그 수정의 일부이며 해당 버그 수정이 중요할 때만 정말 중요합니다.이는 현재 제품과 품질 우선순위에 따라 결정되어야 합니다.다른 노력의 부작용으로 테스트를 생성하는 경우에는 좋지만 실제 우선순위에서 주의가 산만해져서는 안 됩니다.

테스트를 경고로 개선하고 이에 대한 버그를 제출하는 동안 발견된 버그를 만드는 것이 좋습니다.이는 학습한 내용을 실제로 사용하는 동시에 현재 작업을 완료할 수 있는 폭 우선 접근 방식입니다.그런 다음 버그 수정이 예정되어 있으면 테스트를 실제 실패로 쉽게 만들 수 있습니다.

다른 응답자들과 달리 저는 실패가 경고만큼 무시하기 쉽고, 실패를 무시하도록 팀을 교육하는 데 드는 비용이 너무 크다고 생각합니다.이러한 노력의 일환으로 실패한 테스트를 생성하는 경우 작업이 개선될 때 회귀 테스트 도구 모음의 유용성을 파괴하게 됩니다.

Answer 7

테스트에 실패하는 것은 일종의 격자입니다.손상된 코드와 완료되지 않은 코드에는 차이가 있으며, 테스트를 즉시 해결해야 하는지 여부는 실패한 테스트가 어떤 상황에 노출되는지에 따라 달라집니다.

고장난 경우에는 더 늦기 전에 빨리 고쳐야 합니다.아직 끝나지 않았다면 시간이 있을 때 처리하세요.

두 경우 모두 (현재로서는) 나쁘게 행동하는 것을 감수할 수 있으므로 문제가 기록되어 있는 한 문제를 해결할 시간이 있을 때까지 잔소리하지 않는 것이 좋습니다.