단위 테스트 Proof By Example을 수동으로 작성합니까?

JUnit 테스트 작성은 코드를 통한 특정 경로를 보여줍니다.

내 동료 중 하나가 다음과 같이 댓글을 달았습니다.

단위 테스트를 수동으로 작성하는 것은 Proof By Example 입니다.

그는 Quickcheck 와 같은 툴 과 타입으로 프로그램 동작 을 추론 할 수있는 능력을 가진 Haskell의 배경에서왔다 .

그의 의미는 코드가 테스트되지 않은이 방법으로 시도되지 않은 많은 다른 입력 조합이 있다는 것입니다.

내 질문은 : 수동으로 단위 테스트를 작성하고 있습니까?

테스트를 위해 무작위로 입력을 선택하는 경우 Proof By Example 논리 오류가 발생했을 수 있습니다.

그러나 좋은 단위 테스트는 결코 그렇게하지 않습니다. 대신, 그들은 범위 와 가장자리 사례를 다룹니다.

예를 들어 정수를 입력으로 받아들이는 절대 값 함수에 대한 단위 테스트를 작성하는 경우 코드가 작동하는지 증명하기 위해 가능한 모든 입력 값을 테스트 할 필요는 없습니다. 종합적인 테스트를 수행하려면 -1, 0, 1 및 입력 정수의 최대 값과 최소값 만 5 개만 필요합니다.

이 5 개의 값은 가능한 모든 범위와 함수의 경우를 테스트합니다. 함수가 모든 입력 값에 대해 작동하는 높은 신뢰 수준을 얻기 위해 가능한 다른 모든 입력 값 (즉, 정수 유형이 나타낼 수있는 모든 숫자)을 테스트 할 필요는 없습니다.

모든 소프트웨어 테스트는 "Proof By Example"과 유사하며 JUnit과 같은 도구를 사용한 단위 테스트 만이 아닙니다. 그리고 그것은 새로운 지혜가 아닙니다. 1960 년 Dijkstra 의 인용문이 있습니다 .

"테스트는 버그가 아닌 존재를 보여줍니다"

( "shows"라는 단어를 "proofs"로 바꾸십시오). 그러나 이는 임의의 테스트 데이터를 생성하는 도구의 경우에도 마찬가지입니다. 실제 함수에 대한 가능한 입력 수는 일반적으로 해당 사례를 생성하는 방법과 관계없이 우주 시대 내에 예상되는 결과에 대해 생성하고 확인할 수있는 테스트 사례 수보다 몇 배나 더 큰 숫자입니다. 많은 테스트 데이터를 생성하기 위해 생성기 도구를 사용하더라도 특정 버그를 감지 할 수있는 하나의 테스트 사례를 놓치지 않을 것이라는 보장은 없습니다.

무작위 테스트는 때때로 수동으로 생성 된 테스트 사례에서 간과 한 버그를 드러 낼 수 있습니다 . 그러나 일반적으로 테스트 할 함수에 대해 테스트를 신중하게 작성하고 가능한 한 적은 테스트 사례로 전체 코드 및 분기 적용 범위를 확보하는 것이 더 효율적입니다. 때로는 수동 테스트와 무작위 생성 테스트를 결합하는 것이 가능한 전략 일 수 있습니다. 또한 무작위 테스트를 사용할 때 재현 가능한 방식으로 결과를 얻기 위해주의를 기울여야합니다.

따라서 수동으로 생성 된 테스트는 무작위로 생성 된 테스트보다 나쁘지 않으며 종종 반대입니다.

테스트를 수동으로 작성하는 것은 "예제로 증명됩니다". 그러나 QuickCheck 및 제한된 범위의 유형 시스템도 마찬가지입니다. 간단한 공식 검증이 아닌 것은 코드에 대해 알려주는 내용에 제한이 있습니다. 대신, 당신은 접근의 상대적 장점에 대해 생각해야합니다.

QuickCheck와 같은 생성 테스트는 넓은 입력 공간을 청소하는 데 정말 좋습니다. 또한 수동 테스트보다 최첨단 사례를 처리하는 것이 훨씬 낫습니다. 생성 테스트 라이브러리는 현재보다 더 많이 경험할 것입니다. 반면에, 그들은 특정 출력이 아닌 불변에 대해서만 알려줍니다. 따라서 프로그램의 결과가 올바른지 확인하려면 실제로이를 확인하기위한 몇 가지 수동 테스트가 필요합니다 foo(bar) = baz.