열거 형은 단순히 유한 한 유형이며 사용자 정의 (유용한 의미있는) 이름이 있습니다. 열거 형에는 값이 하나만 포함될 수 있습니다 ( void포함 된 것만 포함) null(일부 언어는 이것을 호출 unit하고 요소 void가 없는 열거 형 의 이름 을 사용합니다 !). 이 같은 두 개의 값을 가질 수 bool있다있는을 false하고 true. 이 같은 세 가지가있을 수 colourChannel와 red, green와 blue. 등등.
두 열거 형의 값이 같은 경우 "등방성"입니다. 즉, 모든 이름을 체계적으로 바꾸면 다른 이름 대신 다른 이름을 사용할 수 있으며 프로그램은 다르게 동작하지 않습니다. 특히 테스트 는 다르게 작동하지 않습니다!
예를 들어, result함유 win/ lose/을 draw위의 동형 colourChannel우리가 예를 들어 대체 할 수 있기 때문에, colourChannel와 result, red와 win, green와 lose와 blue와 draw같은 우리가 그렇게로서, 그리고 사방 (생산자와 소비자, 파서 및 serialisers, 데이터베이스 항목, 로그 파일 등 ) 프로그램에 변화가 없습니다. colourChannel우리가 쓴 " 테스트"는 colourChannel더 이상 없어도 통과 할 것입니다!
또한 열거 형에 둘 이상의 값이 포함되어 있으면 항상 해당 값을 재 배열 하여 동일한 수의 값을 가진 새 열거 형을 얻을 수 있습니다. 값의 개수가 변경되지 않았으므로 새로운 배열은 이전 배열과 동형이되므로 모든 이름을 바꿀 수 있고 테스트는 여전히 통과됩니다 ( 정의를 바꿀 수는 없습니다 . 여전히 모든 사용 사이트를 끄십시오).
이것이 의미하는 것은, 기계에 관한 한 열거 형은 "구별 할 수없는 이름"이며 그 밖의 것은 없다는 것 입니다. 열거 형으로 할 수있는 유일한 것은 두 값이 같은지 (예 : red/ red) 또는 다른지 (예 : red/ blue) 를 분기하는 것 입니다. 이것이 '단위 테스트'가 할 수있는 유일한 것입니다.
( red == red ) || throw TestFailure;
(green == green) || throw TestFailure;
( blue == blue ) || throw TestFailure;
( red != green) || throw TestFailure;
( red != blue ) || throw TestFailure;
...
@ jesm00이 말했듯이 이러한 테스트는 프로그램이 아닌 언어 구현을 확인하는 것입니다. 이러한 테스트는 결코 좋은 생각이 아닙니다. 언어 구현을 신뢰하지 않더라도 테스트를 올바르게 실행한다고 신뢰할 수 없으므로 외부 에서 테스트해야합니다!
이것이 이론입니다. 연습은 어떻습니까? 열거 형 의이 특성화의 주요 문제는 '실제 세계'프로그램이 거의 포함되지 않는다는 것입니다. 우리는 레거시 버전, 원격 / 임베디드 배포, 히스토리 데이터, 백업, 라이브 데이터베이스 등을 가지고 있으므로 절대로 '전환'할 수 없습니다. 일부 사용을 놓치지 않고 이름의 모든 발생.
그러나 그러한 것은 열거 자체의 '책임'이 아닙니다. 열거를 변경하면 원격 시스템과의 통신이 중단 될 수 있지만 반대로 열거를 변경하여 이러한 문제를 해결할 수 있습니다 !
이러한 시나리오에서 열거 형은 청각 적입니다. 한 시스템 이 이런 식 이어야 하고 다른 시스템 이 그런 식이어야 한다면 어떻게해야합니까? 얼마나 많은 테스트를 작성하든 상관 없습니다. 여기서 중요한 범인은 입력 / 출력 인터페이스이며, "인터 프리트가 선택하는 정수"가 아니라 잘 정의 된 형식을 생성 / 소비해야합니다. 따라서 실제 솔루션은 i / o 인터페이스 를 테스트하는 것 입니다. 단위 테스트를 통해 예상 형식을 구문 분석 / 인쇄하는지 확인하고 통합 테스트를 통해 형식이 실제로 다른 쪽에서 승인되는지 확인합니다.
우리는 열거 형이 '충분히 충분히 운동'되는지 궁금해 할 수 있지만이 경우 열거 형은 다시 빨간 청어입니다. 우리가 실제로 우려하는 것은 테스트 스위트 자체 입니다. 여기서 몇 가지 방법으로 신뢰를 얻을 수 있습니다.
- 코드 범위는 테스트 스위트에서 나오는 다양한 열거 형 값이 코드의 다양한 분기를 트리거하기에 충분한 지 여부를 알려줍니다. 그렇지 않은 경우, 발견되지 않은 분기를 트리거하는 테스트를 추가하거나 기존 테스트에서 더 다양한 열거를 생성 할 수 있습니다.
- 속성 검사는 코드의 다양한 브랜치가 런타임 가능성을 처리하기에 충분한 지 알려줍니다. 예를 들어 코드가 만 처리
red하고로만 테스트하면 red100 % 적용 범위를 갖습니다. 속성 검사기는 테스트를 위해 잊어 버린 green및 blue값 생성과 같은 어설 션에 대한 반례를 생성하려고 시도합니다 .
- 우리의 주장이 사실인지 돌연변이 시험은 우리를 알 수 있습니다 확인 단지 가지를 다음과 차이점을 무시하기보다는, 열거합니다.