매개 변수화 된 테스트-언제, 왜 사용합니까?

최근 직장에서 우리는 Parameterized testing 과 관련하여 약간의 의견 차이가있었습니다 . 일반적으로 우리는 TDD 스타일 (또는 적어도 시도)을 사용하므로 해당 접근법의 이점을 이해합니다. 그러나 나는 매개 변수가있는 테스트가 가져 오는 것을 보려고 고심하고 있습니다. 참고로 우리는 서비스와 RESTful 인터페이스를 통해 노출되는 라이브러리에서 작업합니다.

지금까지 내가 본 것은 적어도 Eclipse에서 JUnit을 사용하는 테스트입니다.

• 세부 정보 부족-테스트가 실패하면 실패한 매개 변수를보기가 매우 어렵습니다.
• 종종 복잡한 만들기
• 코드가 작성된 후 생성되는 경향이 있습니다. 엄격하게 단점은 아니지만 사람들이 코드를 시작할 때 매개 변수화 된 테스트를 염두에 두어야합니까?

누군가가 실제로 유용한 위치에 대한 예가 있거나 사용하기에 좋은 힌트가 있다면 환상적입니다. 개인적으로 사용하기로 선택하지 않고 테스트 무기고의 일부로 고려해야 할 것이기 때문에 내가 고집을 부리지 않도록하고 싶습니다.

모든 소프트웨어를 테스트 할 때의 문제는 복잡성이 매우 빠르게 터진다는 것입니다. 사실, 메소드에 전달 된 모든 가능한 매개 변수 조합을 테스트 할 수는 없습니다 . Phadke 는 DOE (Design of Experiments) 접근 방식을 옹호하여 테스트가 필요한 매개 변수 값 목록을 생성 할 수 있습니다.

철저한 테스트를하지 않더라도 대부분의 결함으로 인해 격리 지점 오류가 아닌 "오류 영역"이 발생합니다. Phadke의 DOE 접근 방식은 직교 배열을 사용하여 가능한 모든 결함 영역에 도달 할 수있을 정도로 매개 변수 공간을 정밀하게 샘플링합니다.

분리 된 결함은 식별되지 않지만 일반적으로 결함 영역보다 적습니다.

DOE 접근 방식은 매개 변수 값을 다양하게 선택할 수있는 체계적인 방법을 제공합니다.

그것들은 코드가 행복한 길뿐만 아니라 가장 중요한 경우를 처리하도록하는 데 유용 할 수 있습니다. 코드가 일반 변수와 함께 작동한다는 것을 알면 테스트 사례를 매개 변수화하고 null 및 0, 빈 문자열, 큰 숫자, 긴 문자열, 이상한 유니 코드 문자 등이 제대로 작동하는지 확인하십시오.

적어도 JUnit 4.8에는 두 가지 이상의 매개 변수화 된 테스트가 있습니다. @RunWith(Parameterized.class)사전 정의 된 매개 변수 구성을 생성 / 읽는 데이터 소스를 필요로하는 매개 변수화 된 테스트 ( ) 및 @RunWith(Theories.class)인수 유형 당 하나 이상의 가능한 입력 세트가 제공된 경우 제공된 메소드의 스펙을 실행할 수있는 이론 ( ). 다음과 같이 보입니다.

• @DataPoints문자열 인수에 가능한 값 ( )을 지정하십시오 (예 null: 빈 문자열, 비어 있지 않은 문자열, 실제로 긴 문자열)
• @DataPointsAnimal 클래스 인수에 가능한 값 ( )을 지정하십시오 (예 null: Dog인스턴스, Cat인스턴스, Bird인스턴스)
• 매개 변수와 매개 변수 @Theory를 허용하는 준비하십시오 . 가능한 매개 변수 값의 가능한 모든 조합으로 실행됩니다 (주어진 예에서 ( , )를 포함하여 4x4 = 16 조합 )StringAnimalnullnull
• 테스트중인 메소드가 일부 조합을 승인 할 수없는 경우 Assume.assumeThat정적 가져 오기를 사용 하여 유효하지 않은 조합을 필터링하십시오 (예 : 비어 있지 않은 문자열에 대한 메소드의 동작을 확인하려는 경우 첫 번째 행 중 하나는 "널이 아닌 것으로 가정")

이전에 작성된 것처럼 모든 방법의 가능한 모든 조합을 테스트하는 것은 이치에 맞지 않습니다 (테스트 세트를 분해하고 5 개의 매개 변수로 메소드를 테스트하는 것을 상상해보십시오. 각 매개 변수는 5 개의 가능한 값을가집니다. 5 ** 5-> 3000 회 이상의 테스트 실행) !), 그러나 API (메소드 메소드와 같은) 미션 크리티컬 메소드의 경우, 안전한 측면에있는 것이 좋습니다.

일반적인 예 :

• 문자열 인수가있는 메소드 매개 변수화 된 테스트를 사용하여 다른 입력 및 예상 출력을 테스트하십시오. 각 쌍에 대한 TC를 작성하는 것보다 쌍 목록 (입력, 예상)을 갖는 것이 훨씬 실용적입니다.

• 다른 인수에 동일한 시나리오를 적용하십시오. 우리는 함께 작동하는 시나리오가 Animal객체와 같은 서브 클래스의 여지가를 Dog, Cat, Bird. 사용 가능한 동물 목록을 작성하고 시나리오를 테스트하십시오.

웹 서비스를위한 구체적 :

• 위의 문자열 인수 예제에서. 동일한 유형이지만 다른 값의 다른 인수로 발생하는 상황을 테스트하십시오.

매개 변수화 된 테스트는 다양한 입력을 테스트하려는 경우 입력이 간단한 기능 / 기능을 테스트하는 데 적합합니다.

다른 기능과 복잡한 입력을 테스트하는 데 적합하지 않습니다. 적은 코드를 작성하기위한 편의 구조로 사용해서는 안됩니다.

TDD-ish 방식으로 많은 매개 변수가있는 테스트를 사용하는 한 가지 사례는 파서를 작성하는 것입니다. 입력 및 예상 출력 인 경우 목록으로 시작한 다음 모든 테스트 사례를 통과하도록 코드를 작성할 수 있습니다.

그러나 매개 변수 테스트의 몇 가지 공포를 보았습니다. 아니요, 버지니아 테스트 스위트에는 자체 단위 테스트가 필요하지 않습니다.