프로덕션에서 버그가 발견되면 의도적으로 빌드를 중단해야합니까?

최종 사용자의 프로덕션에서 심각한 버그가 발견되면 해당 버그를 커버하기 위해 실패한 단위 테스트를 추가하여 버그가 수정 될 때까지 의도적으로 빌드를 중단하는 것이 합리적입니다. 이것에 대한 나의 근거는 빌드 가 완전히 실패 했어야 하지만 자동 테스트 범위가 충분하지 않기 때문이 아니라는 것이다.

내 동료 중 일부는 실패한 단위 테스트를 체크인하지 말아야한다는 의견에 동의하지 않았습니다. 일반적인 TDD 관행 측면에서이 견해에 동의하지만 생산 버그를 다르게 처리해야한다고 생각합니다. 알려진 결함으로 성공하기위한 빌드?

다른 사람이이 시나리오를 처리하기위한 전략을 입증 했습니까? 의도적으로 빌드를 중단하면 다른 팀 구성원에게는 지장을 줄 수 있지만 이는 전적으로 지점을 사용하는 방법에 달려 있습니다.

우리의 전략은 다음과 같습니다

실패한 테스트를 확인하지만로 주석을 답니다 @Ignore("fails because of Bug #1234").

그렇게하면 테스트가 있지만 빌드가 중단되지 않습니다.

물론 버그 DB에서 무시 된 테스트를 확인 했으므로 @Ignore테스트가 수정되면 제거됩니다. 또한 버그 수정을 쉽게 확인할 수 있습니다.

실패한 테스트에서 빌드를 중단하는 것은 팀에 압력을 가하는 것이 아니라 문제를 경고하는 것입니다. 버그 DB에서 문제가 확인되고 제기되면 모든 빌드에 대해 테스트를 실행할 필요가 없습니다. 실패 할 것입니다.

물론, 버그는 여전히 수정되어야합니다. 그러나 수정 일정을 예약하는 것은 비즈니스 결정이므로 실제로 개발자의 관심사는 아닙니다. 버그 DB에 버그가 제기되면 고객 / 제품 소유자가 수정을 원한다고 말할 때까지 더 이상 내 문제가 아닙니다. .

알려진 결함으로 빌드가 성공하도록하려는 이유는 무엇입니까?

때로는 시간 제약이 있기 때문입니다. 또는 버그가 너무 작아서 단위 테스트 및 수정에 필요한 며칠 동안 제품 배송을 지연시킬 가치가 없습니다.

또한 버그를 발견 할 때마다 의도적으로 빌드를 중단하는 요점은 무엇입니까? 찾은 경우 전체 팀을 방해하지 말고 수정하십시오 (또는 수정할 담당자에게 지정). 버그 수정을 기억하려면 버그 추적 시스템에서 버그를 매우 중요하게 표시해야합니다.

문제가 발생하지 않도록 다시 테스트합니다. 실패한 테스트 목록은 버그 추적 시스템을 대체하지 않습니다. POV에는 실패한 테스트가 버그의 표시 일뿐 아니라 개발 프로세스 실패 (부주의에서 잘못 식별 된 종속성까지)의 표시이기도합니다.

"빌드 중단"은 빌드가 성공적으로 완료되지 않도록하는 것을 의미 합니다 . 실패한 테스트는 그렇게하지 않습니다. 빌드에 알려진 결함이 있음을 나타내며 이는 정확히 맞습니다.

대부분의 빌드 서버는 시간이 지남에 따라 테스트 상태를 추적하고 추가 된 이후 실패한 테스트에 다른 분류를 할당하고 (통과에 사용되거나 더 이상 사용하지 않는 테스트), 회귀가 발생했습니다.

실패한 테스트를 추가해야하지만 "실패한 테스트"라고 명시 적으로 말해서는 안됩니다.

@BenVoigt가 그의 대답 에서 지적했듯이 , 실패한 테스트가 반드시 "빌드를 파괴"하지는 않습니다. 용어는 팀마다 다를 수 있지만 코드는 여전히 컴파일되며 제품은 여전히 ​​실패한 테스트와 함께 제공 될 수 있습니다.

이 상황에서 스스로에게 물어봐야 할 것은

수행해야 할 테스트는 무엇입니까?

테스트가 모든 사람이 코드에 대해 좋은 느낌을 갖도록하기 위해 실패한 테스트를 추가하면 모든 사람이 코드에 대해 나쁜 느낌을 갖도록하는 것이 생산적으로 보이지 않습니다. 그러나 테스트가 처음에 얼마나 생산적인가?

내 주장은 테스트가 비즈니스 요구 사항을 반영해야한다는 것 입니다. 는 "버그"는 요구가 제대로 충족되지 나타냅니다 발견 된 경우에 따라서, 다음은 또한 테스트가 제대로 또는 완전히 비즈니스 요구 사항을 반영하지 않습니다 있다는 표시입니다.

그것은 먼저 수정해야 할 버그입니다. "실패한 테스트 추가"가 아닙니다. 당신이있어 수정 비즈니스 요구 사항을보다 정확하게 반영되어야 할 시험 항목을. 코드가 이러한 테스트를 통과하지 못하면 좋은 것입니다. 테스트가 일을하고 있다는 것을 의미합니다.

코드 수정의 우선 순위는 비즈니스에 의해 결정됩니다. 그러나 테스트가 수정 될 때까지 우선 순위를 결정할 수 있습니까? 비즈니스는 정확히 무엇이 실패하고, 어떻게 실패하고, 왜 우선 순위에 대한 결정을 내리기 위해 실패하는지에 대한 지식으로 무장해야합니다. 테스트에서이를 표시해야합니다.

완전히 통과하지 못한 테스트를받는 것은 나쁘지 않습니다. 알려진 문제의 우선 순위를 정하고 그에 따라 처리 할 수있는 큰 이슈를 만듭니다. 그러나 완전하게 테스트 되지 않는 테스트 는 문제입니다. 테스트 자체의 가치에 의문을 제기합니다.

다른 말로하면 ... 빌드가 이미 고장났습니다. 당신이 결정하는 것은 그 사실에주의를 기울 일지 여부입니다.

테스트 자동화 팀에서는 테스트 결함이 아닌 제품 결함으로 인해 실패하는 한 실패한 테스트를 체크인합니다. 이런 식으로 우리는 개발자 팀에게 증거를 얻었습니다. 빌드를 깨는 것은 매우 어리석은 일이지만 완벽하게 컴파일 가능하지만 실패한 테스트를 체크인하는 것과는 다릅니다.

버그가 수정 될 때까지 실패 할 것이라는 테스트를 작성하는 것이 좋습니다. 이는 TDD의 기초입니다.

빌드를 깨는 것은 나쁜 생각입니다. 왜? 그것은 고정 될 때까지 아무것도 움직일 수 없다는 것을 의미하기 때문입니다. 본질적으로 개발의 다른 모든 측면을 차단합니다.

예제 1
구성 요소가 많고 응용 프로그램이 큰 경우 어떻게됩니까? 다른 팀에서 자체 릴리스 주기로 해당 구성 요소를 작업하는 경우 어떻게됩니까? 강인한! 그들은 당신의 버그 수정을 기다려야합니다!

예제 2
첫 번째 버그를 수정하기 어려운데 우선 순위가 더 높은 다른 버그 를 찾으면 어떻게합니까? 또한 두 번째 버그에 대한 빌드를 중단합니까? 이제 둘 다 고정 될 때까지 빌드 할 수 없습니다 . 인공적인 의존성을 만들었습니다.

테스트 실패가 빌드를 중지해야하는 논리적 이유는 없습니다. 이것은 개발자 팀이 알려진 버그로 빌드를 릴리스하는 장단점을 평가하기 위해 (관리 토론과 함께) 결정 해야하는 결정입니다. 이것은 소프트웨어 개발에서 매우 일반적이며, 거의 모든 주요 소프트웨어는 최소한으로 출시 몇 가지 알려진 문제.

테스트가 수행해야 할 역할과 그 결과가 채택 된 빌드 시스템 / 프로세스에 어떤 영향을 미치는지에 따라 다릅니다. 빌드를 깨는 것에 대한 나의 이해는 Ben과 동일하며 동시에 기존 테스트를 중단하는 코드를 의도적으로 체크인해서는 안됩니다. 이러한 테스트가 "나중에"들어온 경우, 다른 테스트를 불필요하게 방해하지 않도록 무시하는 것이 "좋아"일 수 있지만, 실패한 테스트를 무시하는 (실제로 보이기 위해) 무시하는이 관행은 다소 혼란 스럽습니다 (특히 빨간색 또는 녹색이 아닌 테스트를 나타내는 방법이없는 한 단위 테스트의 경우).

물론 버그에 따라 다르지만 일반적으로 수동 또는 자동 테스트 중에 식별되지 않은 문제가 발생하면 적용 범위에 차이가 있음을 의미합니다. 근본적인 원인을 파악하고 문제 위에 단위 테스트 사례를 두드리는 것이 좋습니다.

유지 관리 지점에서 핫픽스를 계획 한 프로덕션 문제인 경우에도 수정 프로그램이 기본에서 작동하는지 확인하고 개발자가 지나치게 열성적인 병합 충돌 해결로 수정 프로그램을 잘못 날릴 수 없도록해야합니다. .

또한 릴리스 정책에 따라 새로 업데이트 된 단위 테스트가 있으면 개발자가 문제를 단순히 [문제 또는 테스트?]로 변경하지 않고 실제로 문제를 해결했는지 확인하는 데 도움이 될 수 있습니다. 새로운 단위 테스트에서 올바른 요구 사항.

빌드에 실패 테스트를 추가 할 때의 한 가지 문제점은 팀이 빌드 실패를 예상하기 때문에 실패한 테스트를 무시하는 습관이 생길 수 있다는 것입니다. 빌드 시스템에 따라 다르지만 실패한 테스트가 항상 "무엇이 고장났다"는 의미는 아니라면 실패한 테스트에 덜주의를 기울이는 것이 쉽습니다.

당신은 당신의 팀이 그런 사고 방식을 갖도록 돕고 싶지 않습니다.

따라서 테스트를 추가 해야 하지만 버그가 수정 될 때까지 자동 빌드 목적 으로 '무시'로 표시 해야한다는 썰매에 동의합니다 .

어떤 식 으로든 버그를 테스트로 '체크 인'해야한다고 생각하지만 버그를 수정하면 다시 발생하지 않으며 우선 순위를 매기므로 빌드를 중단하지 않는 것이 가장 좋습니다 (/ 테스트) . 그 이유는 후속 빌드 커밋이 깨진 테스트 뒤에 숨겨지기 때문입니다. 따라서이 버그에 대해 깨진 테스트를 확인하면 팀 전체가이 버그를 해결하기 위해 작업을 정리해야합니다. 이것이 발생하지 않으면 추적 할 수없는 커밋을 중단 할 수 있습니다.

따라서 테스트를 보류 테스트로 커밋하는 것이 좋으며 팀에서 테스트를 보류하지 않는 것을 우선 순위로 둡니다.

또 다른 옵션은 실패한 테스트를 소스 제어 시스템의 별도 분기로 검사하는 것입니다. 당신의 관행에 따라, 이것은 가능하거나 그렇지 않을 수 있습니다. 때때로 사소하지 않은 버그 수정과 같은 지속적인 작업을 위해 새로운 지점을 개설합니다.