테스트 범위는 적절한 코드 품질 측정입니까?

테스트 범위가 80 % 인 모든 코드가있는 경우 (모든 테스트 통과) 테스트 범위가없는 코드보다 품질이 높다고 말하는 것이 공정합니까?

아니면 유지 관리가 더 쉽다고 말하는 것이 공평합니까?

엄격한 의미에서 테스트 스위트의 품질이 확립 될 때까지 어떠한 주장도하는 것은 불공평합니다. 대부분의 테스트가 사소하거나 반복적이라면 테스트의 100 %를 통과하는 것은 의미가 없습니다.

문제는 프로젝트의 역사에서 이러한 테스트 중 버그가 발견 되었습니까? 테스트의 목표는 버그를 찾는 것입니다. 그렇지 않은 경우 테스트로 실패했습니다. 코드 품질을 향상시키는 대신 잘못된 보안 감각 만 제공 할 수 있습니다.

테스트 설계를 개선하기 위해 (1) 화이트 박스 기술, (2) 블랙 박스 기술 및 (3) 돌연변이 테스트를 사용할 수 있습니다.

(1) 다음은 테스트 설계에 적용 할 수있는 유용한 화이트 박스 기술입니다. 화이트 박스 테스트는 특정 소스 코드를 염두에두고 구성됩니다. 화이트 박스 테스트의 중요한 측면 중 하나는 코드 범위입니다.

• 모든 함수가 호출됩니까? [기능 범위]
• 모든 진술이 실행됩니까? [발표 범위-기능적 범위와 진술 범위는 매우 기본적이지만 아무것도 아닌 것보다 낫습니다]
• ( if또는 같은 while) 모든 결정에 대해 , 당신은 그것이 사실이되도록 강요하고 다른 것은 그것이 거짓이되도록 강요합니까? [결정 범위]
• 연결 (uses &&) 또는 분리 (uses ||) 인 모든 조건에 대해 각 하위 표현식에 참 / 거짓 테스트가 있습니까? [조건 범위]
• 루프 적용 범위 : 반복 0 회, 반복 1 회, 반복 2 회를 ​​수행하는 테스트가 있습니까?
• break루프에서 각각 덮여 있습니까?

(2) 블랙 박스 기술은 요구 사항이있을 때 사용되지만 코드 자체는 그렇지 않습니다. 이는 고품질 테스트로 이어질 수 있습니다.

• 블랙 박스 테스트는 여러 테스트 목표를 포괄합니까? 테스트는 "지방"이되기를 원할 것입니다. 기능 X를 테스트 할뿐만 아니라 Y와 Z도 테스트합니다. 서로 다른 기능의 상호 작용은 버그를 찾는 좋은 방법입니다.
• "지방"테스트를 원하지 않는 유일한 경우는 오류 조건을 테스트 할 때입니다. 예를 들어, 유효하지 않은 사용자 입력을 테스트합니다. 여러 개의 유효하지 않은 입력 테스트 목표 (예 : 유효하지 않은 우편 번호 및 유효하지 않은 주소)를 달성하려는 경우 한 사례가 다른 사례를 마스킹했을 수 있습니다.
• 입력 유형을 고려하고 입력 유형에 대한 "동등 클래스"를 형성하십시오. 예를 들어, 코드에서 삼각형이 등변인지 확인하기 위해 변 (1, 1, 1)이있는 삼각형을 사용하는 테스트는 테스트 데이터 (2, 2, 2) 및 (3, 3, 3)을 찾을 수 있습니다. 다른 종류의 입력을 생각하면서 시간을 보내는 것이 좋습니다. 예를 들어, 프로그램이 세금을 처리하는 경우 각 세금 괄호에 대한 테스트가 필요합니다. [이를 동등성 분할이라고합니다.]
• 특별한 경우는 종종 결함과 관련이 있습니다. 테스트 데이터에는 동등성 작업의 위, 위 또는 아래와 같은 경계 값이 있어야합니다. 예를 들어 정렬 알고리즘을 테스트 할 때는 빈 배열, 단일 요소 배열, 두 요소가있는 배열 및 매우 큰 배열로 테스트해야합니다. 입력뿐만 아니라 출력도 경계 사례를 고려해야합니다. [이것은 통화 경계 값 분석입니다.]
• 또 다른 기술은 "오류 추측"입니다. 프로그램을 중단시킬 수있는 특별한 조합을 시도 할 때 느낌이 있습니까? 그런 다음 시도해보십시오! 기억하십시오 : 귀하의 목표는 프로그램이 유효한지 확인하지 않고 버그를 찾는 것입니다 . 어떤 사람들은 오류 추측에 대한 요령을 가지고 있습니다.

(3) 마지막으로 화이트 박스 적용 범위에 대한 훌륭한 테스트가 많이 있고 블랙 박스 기술을 적용했다고 가정합니다. 너는 어떤 다른 일을 할 수 있니? 테스트 를 테스트 할 차례 입니다. 사용할 수있는 기술 중 하나는 돌연변이 테스트입니다.

돌연변이 테스트에서는 버그를 만들기 위해 프로그램을 (사본) 수정합니다. 돌연변이는 다음과 같습니다.

한 변수의 참조를 다른 변수로 변경하십시오. abs () 함수를 삽입하십시오. 보다 작거나 크게 변경; 문장을 삭제하십시오. 변수를 상수로 바꾸십시오. 재정의 방법을 삭제하십시오. 수퍼 메소드에 대한 참조를 삭제하십시오. 인수 순서 변경

프로그램의 여러 위치에 수십 개의 돌연변이 체를 만듭니다 [테스트하려면 프로그램을 컴파일해야합니다]. 테스트에서 이러한 버그를 찾지 못하면 이제 돌연변이 된 버전의 프로그램에서 버그를 찾을 수있는 테스트를 작성해야합니다. 테스트에서 버그가 발견되면 돌연변이를 죽이고 다른 것을 시도 할 수 있습니다.

부록 :이 효과를 언급하는 것을 잊었습니다. 버그는 클러스터되는 경향이 있습니다 . 즉, 한 모듈에서 더 많은 버그를 발견할수록 더 많은 버그를 발견 할 가능성이 높아집니다. 따라서 테스트에 실패한 경우 (즉, 목표는 버그를 찾는 것이므로 테스트에 성공한 경우) 버그를 수정해야 할뿐만 아니라 모듈을위한 더 많은 테스트를 작성해야합니다. 위의 기술.

꾸준한 속도로 버그를 발견하는 한 테스트 노력을 계속해야합니다. 새로운 버그 발생률이 감소한 경우에만 해당 개발 단계에서 테스트를 잘 수행했음을 확신해야합니다.

하나의 정의에 따르면 테스트에서 주요 변경 사항이 발견 될 가능성이 높으므로 유지 관리가 더 쉽습니다.

그러나 코드가 단위 테스트를 통과한다고해서 본질적으로 고품질이라는 의미는 아닙니다. 코드는 여전히 관련없는 주석과 부적절한 데이터 구조로 형식이 잘못되었을 수 있지만 여전히 테스트를 통과 할 수 있습니다.

유지하고 확장하기를 원하는 코드를 알고 있습니다.

테스트가 전혀없는 코드는 매우 높은 품질, 읽기 쉽고 아름답고 효율적 (또는 전체 정크) 일 수 있으므로 테스트 범위가 80 % 인 코드가 테스트 범위가없는 코드보다 품질이 높다고 말하는 것은 불공평합니다.

80 %가 덮여 그 코드 과언이 될 수 좋은 테스트가 아마도 허용 품질, 그리고 아마도 상대적으로 유지 보수. 그러나 실제로는 거의 보장하지 않습니다.

나는 그것을 더 리팩터링이라고 부를 것이다. 코드에 많은 테스트가 포함되어 있으면 리팩토링이 매우 쉬워집니다.

좀 더 유지 보수가 가능하다고 부르는 것이 공정합니다.

유지 보수 가능한 부분에 동의합니다. 마이클 페더스 (Michael Feathers)는 최근 자신의 " 테스트 가능성과 우수한 디자인 사이의 깊은 시너지 효과 "라는 주제 에 대한 토론을하는 비디오를 게시했습니다 . 대화에서 그는 관계가 한 가지 방법, 즉 잘 설계된 코드는 테스트 가능하지만 테스트 가능한 코드는 반드시 잘 설계된 것은 아니라고 말합니다.

비디오 스트리밍이 비디오에서 좋지 않다는 점에 주목할 가치가 있으므로 전체를보고 싶다면 다운로드 할 가치가 있습니다.

나는 "조건 범위"와 관련하여 한동안이 질문을하고있다. atollic.com의 "왜 코드 범위 분석입니까?" 의이 페이지는 어떻 습니까?

보다 기술적으로 코드 적용 범위 분석은 프로그램에서 테스트 사례에 포함되지 않는 영역을 찾아서 테스트되지 않은 프로그램 부분을 포함하는 추가 테스트를 만들 수 있습니다. 따라서 코드 범위는 코드 자체의 품질이 아니라 테스트 절차의 품질을 이해하는 데 도움이 된다는 것을 이해하는 것이 중요 합니다 .

이것은 여기서 매우 관련이있는 것 같습니다. 특정 수준의 (코드 또는 기타) 적용 범위를 달성하도록 관리하는 테스트 케이스 세트가있는 경우 다소 철저한 입력 값 세트로 테스트중인 코드를 호출 할 가능성이 높습니다! 이것은 코드가 터지거나 감지 가능한 결함을 생성하지 않는 한 테스트중인 코드에 대해 많이 알려주지 않지만 테스트 사례 세트에 대한 자신감을줍니다 .

흥미로운 Necker Cube 보기 변경에서 이제 테스트 코드가 테스트중인 코드에 의해 테스트되고 있습니다!

프로그램이 의도 한대로 작동하도록 보장하고 수정이 의도하지 않은 영향을 미치지 않도록하는 방법은 여러 가지가 있습니다.

테스트는 하나입니다. 데이터의 돌연변이를 피하는 것도 또 다른 방법입니다. 타입 시스템도 마찬가지입니다. 또는 정식 검증.

따라서 테스트는 일반적으로 좋은 일이지만 동의하는 비율은 많지 않을 수 있습니다. 차라리 잘 테스트 된 PHP 라이브러리보다 테스트없이 Haskell로 작성된 것에 의존하고 싶습니다.