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

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

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

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

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

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

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

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

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

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

답변