실패한 단위 테스트에서 확인하는 값은 무엇입니까?

단위 테스트가 실행되지 않도록하는 방법이 있지만 실패한 단위 테스트에서 확인하는 값은 무엇입니까?

간단한 예를 사용하겠습니다. 대소 문자 구분. 현재 코드는 대소 문자를 구분합니다. 메소드에 유효한 입력은 "Cat"이며 Animal.Cat의 열거 형을 리턴합니다. 그러나 방법의 원하는 기능은 대소 문자를 구분해서는 안됩니다. 따라서 설명 된 방법이 "cat"을 전달하면 Animal.Cat 대신 Animal.Null과 같은 것을 반환 할 수 있으며 단위 테스트가 실패합니다. 간단한 코드 변경만으로도이 작업을 수행 할 수 있지만보다 복잡한 문제를 해결하는 데 몇 주가 소요될 수 있지만 단위 테스트로 버그를 식별하는 것은 덜 복잡한 작업 일 수 있습니다.

현재 분석중인 응용 프로그램에는 "작동"하는 4 년 코드가 있습니다. 그러나 단위 테스트에 관한 최근의 논의는 코드에서 결함을 발견했습니다. 일부는 명시적인 구현 문서 (예 : 대소 문자 구분) 또는 현재 호출 방식에 따라 버그를 실행하지 않는 코드 만 필요합니다. 그러나 특정 시나리오를 실행하여 버그를보고 유효한 입력을하는 단위 테스트를 만들 수 있습니다.

누군가가 코드를 고칠 수있을 때까지 버그를 일으키는 단위 테스트를 검사하는 가치는 무엇입니까?

이 단위 테스트에 무시, 우선 순위, 범주 등으로 플래그를 지정하여 실행 된 테스트를 기반으로 빌드가 성공적인지 여부를 판별해야합니까? 결국 누군가가 코드를 수정하면 코드를 실행하기 위해 단위 테스트를 작성해야합니다.

한편으로는 식별 된 버그가 수정되지 않았 음을 보여줍니다. 다른 한편으로, 로그에 수백 개의 실패한 단위 테스트가 표시 될 수 있으며, 코드 체크인으로 인한 실패와 실패한 테스트를 찾아내는 것이 어려울 수 있습니다.

나는 불필요한 단위 테스트가 불필요한 노이즈를 생성하기 때문에 체크인하는 것을 좋아하지 않습니다 . 모든 단위 테스트 후에 모든 실패한 문제 (빨간색)를 확인해야합니다. 새로운 문제가 있거나 수정해야 할 오래된 문제가 있기 때문에 빨간색입니까? 단위 테스트가 20 개 이상인 경우에는 괜찮습니다.

대신에 나는

• [Ignore("Reason")]결과를 노란색 또는
• throw new NotImplementedException()결과를 회색으로 만듭니다.

참고 : .net에 NUnit을 사용하고 있습니다. "회색"기능이 다른 단위 테스트 프레임 워크에 있는지 확실하지 않습니다.

그래서 나는 단위 테스트 결과의 다음 의미를 좋아합니다.

• 녹색 : 모두 완료
• 회색 : 수행해야하지만 우선 순위가 낮은 계획된 새로운 기능
• 노랑 : 아직 수정되지 않은 버그. 곧 고쳐야한다
• 빨간색 : 새로운 버그. 즉시 수정해야합니다

"빨간색"을 제외한 모든 항목을 체크인 할 수 있습니다.

질문에 대답하기 위해 : "적색 실패 테스트"에서 확인하는 값보다 더 많은 피해가 있지만 "노란색 무시 테스트"또는 "회색 NotImplementedYet- 테스트"에서 확인하는 것이 할 일 목록으로 유용 할 수 있습니다.

나는 이것이 산업 표준 인 척하지는 않지만 나 또는 다른 프로젝트 참여자에게 여전히 코드 또는 단위 테스트 자체에 여전히 문제가 있음을 상기시키는 방법으로 깨진 테스트를 확인합니다.

고려해야 할 한 가지 사항은 개발 정책이 페널티없이 실패한 테스트를 허용하는지 여부입니다. 테스트 중심 개발을 수행하는 상점에서 일하는 친구가 있으므로 항상 테스트 실패로 시작합니다.

실패한 단위 테스트를 통해 개발 팀은 합의 된 사양을 준수하기 위해 수행해야 할 작업을 파악할 수 있습니다.

요컨대, 실패한 단위 테스트는 팀에게 "TODO"목록을 제공합니다.

이러한 이유로 단위 테스트 실패는 단위 테스트가 전혀 없는 것보다 훨씬 낫습니다. *
단위 테스트가 없으면 개발 팀은 어둡게됩니다. 사양은 수동으로 반복해서 확인 해야 합니다.

[* 단위 테스트는 실제로 유용한 것을 테스트했습니다.]

단위 테스트의 목적은 결함을 문서화하지 않고 시스템의 예상 동작을 확인하는 것입니다. 단위 테스트를 사용하여 결함을 문서화하면 예상 동작을 확인하는 데 유용성이 떨어집니다. "이 테스트는 왜 실패 했습니까?"라는 질문에 대한 답변 "아, 내가 부러 질 것으로 예상되지 않은 무언가가 깨졌습니다." 테스트 실패가 예상되는지 예기치 않은지 알 수 없습니다.

다음은 레거시 코드를 효과적으로 사용하기위한 13 장 시작 부분의 단락입니다 .

자동화 된 단위 테스트는 매우 중요한 도구이지만 최소한 버그 찾기에는 적합하지 않습니다. 일반적으로 자동화 된 테스트는 이미 존재하는 동작을 수행하거나 유지하려는 목표를 지정해야합니다. 개발의 자연스러운 흐름에서, 테스트 그게 지정할 테스트하게 유지 . 버그를 찾을 수 있지만 일반적으로 테스트를 처음 실행할 때는 아닙니다. 예상치 못한 동작을 변경하면 나중에 실행되는 버그가 발견됩니다.

그러나 새로운 프로젝트에서 버그를 식별하는 깨진 버그는 이와 같은 이름을 갖습니다. 그렇게하면 그들이 깨져야한다는 것을 알 수 있습니다 ... 그들이 고쳐질 때, 그들은 녹색으로 바뀌어 일반 테스트 스위트로 옮겨 질 것입니다.

참고 : 빌드 서버가 빌드를 중단시키는 체크인을 방지하는 경우 (모든 테스트가 통과되지 않는 깨진 빌드를 정의한 경우) 해당 프로젝트를 빌드 서버에 빌드하지 않도록 설정해야합니다.

단위 테스트는 함수의 성공 사례 외에도 오류 사례를 테스트해야합니다. 함수는 잘못된 입력을 명시 적으로 거부하거나 어떤 입력이 유효한지 설명하는 문서를 가져야합니다.

이러한 작업 중 하나를 수행하지 않는 기능이있는 경우 이는 버그이므로 해당 기능을 기록 할 수있는 방법이 있어야합니다. 이 문제를 보여주는 단위 테스트를 작성하는 것이 한 가지 방법입니다. 버그 티켓을 제출하는 것도 또 다른 옵션입니다.

단위 테스트의 요점은 100 % 성공하는 것이 아니라 코드에서 버그를 찾아 수정하는 것입니다. 테스트를하지 않는 것은 100 % 성공을 거두는 쉬운 방법이지만 프로젝트에는 그다지 도움이되지 않습니다.

모든 실패에 대한 버그를 신고하고 테스트 결과에 유의하십시오. 그런 다음 행동을 취하고 버그를 수정하면 테스트에 합격하고 테스트 결과에서 해당 버그를 삭제합니다. 문제를 무시하지 마십시오.

완료되지 않은 코드에 대한 테스트 구현으로 TDD가 수행되는 것을 보는 방법은 먼저 [ExpectedException] 속성 또는 이와 유사한 테스트를 작성하십시오. 불완전한 코드에는 논리가 없으므로 새로운 Exception () 던지기 코드를 작성하므로 처음에는 전달해야합니다. 예외 처리가 잘못되었지만 테스트를 처음에 통과하고 체크인에 적합하게 만들 수 있습니다. 우리는 무시 된 테스트를 잊어 버릴 수 있지만 불완전한 코드를 정리하거나 채울 수 있습니다. 그렇게하면 예외가 예상되는 해당 테스트가 자동으로 실패하기 시작하고이를 해결하도록 경고합니다. ExpectException을 제거하기 위해 테스트를 약간 변경하고 대신 실제 어설 션을 수행 할 수 있습니다. CI, 개발자, 테스터 및 고객 모두 행복하고 상생하는 상황입니까?