단위 테스트 및 긴 설치 문자열 : 스타일/모범 사례

Question

단위 테스트에서 긴 설치 문자열을 사용하는 것에 대한 의견, 실제 및 권장 모범 사례에 관심이 있습니다.

테스트를 곧바로 선언하고, 테스트에 가까우며, 어딘가에 파일로 외부화 하시겠습니까?

참고 : 저는 단일 단위 테스트에만 해당되는 테스트 자산에 대해 말하고 있습니다. 따라서 setup() 메소드에 반드시 필요한 것은 아닙니다.

나는 양쪽 모두의 장점과 단점을 보았습니다. 저는 테스트에 가능한 한 가깝게 테스트를 중요하게 생각합니다.하지만 몇 줄의 문자열 설정은 테스트 방법에서 빠르게 변경 될 수 있습니다.

예를 들어, 파일에서 사용되지 않은 CSS 선언을 제거하는 빠른 파서를 작성하고 있습니다. 특정 입력 문자열이 주어지면 올바른 텍스트가 제거되었는지 테스트하고 싶습니다. 모든 문자열 연결을 통해 내 테스트가 실제로 시끄 럽습니다.

이 예를 감안할 때

public void removesStyleFromText() 
{ 
    StyleCleaner styleCleaner = new StyleCleaner(); 
    String source = ".presentInFileOne {\r\n" + 
      "}\r\n" + 
      "\r\n" + 
      ".presentInFileTwo {\r\n" + 
      " bottom-corners-rounded : false;\r\n" + 
      "}\r\n" + 
      ".notUsed {\r\n" + 
      "}\r\n" + 
      ""; 

    String actual = styleCleaner.removeDeclaration(source , "notUsed"); 

    String expected = ".presentInFileOne {\r\n" + 
    "}\r\n" + 
    "\r\n" + 
    ".presentInFileTwo {\r\n" + 
    " bottom-corners-rounded : false;\r\n" + 
    "}\r\n"; 

    assertEquals(expected , actual); 
} 

, 나는 외부 파일로 예상/실제를 구체화 할 수 있지만,이 또한 사실에 대한 테스트 있는지에 관해서는 조금 불분명 테스트를합니다.

생각하십니까?

Answer 1

개인적으로 이와 같은 경우 문자열을 인라인으로 유지하는 것을 선호합니다. 문자열은 테스트에서 수행해야 할 작업을 이해하는 데 중요하므로 외부에서이를 조회해야하는 것이 비생산적인 것으로 보입니다.

문자열이 어느 정도 들어가는 지와 문자열이 다른지에 대해서만 다른 동일한 테스트를 많이 수행하는 경우 이야기가 약간 다릅니다. 테이블 기반 테스트 솔루션을 살펴 보는 것이 좋습니다. .Net에서 당신은 mbunit을 가지고 있습니다. 그것은 당신이 다른 예상 입출력으로 동일한 테스트를 수행 할 수있게하거나 테스트하고자하는 데이터 테이블을 정의 할 수있는 Fitnesse와 같은 툴을 볼 수 있습니다.

Answer 2

문자열을 외부화하고 테스트 할 내용에 대한 의견을 작성합니다. 주석은 이러한 문자열 구조보다 훨씬 더 읽기 쉽다는 장점이 있습니다.

Answer 3

확실히 코드를 작성하면 테스트 대상을 바로 알 수 있고 재사용 할 때 리팩토링하기가 훨씬 쉽습니다. 나는 건조하게 유지하고 싶다. 그래서 나는 보통 빌더 나 콘크리트 수업 (내가하고있는 일에 따라 다름)으로 옮겨가는 경향이 있는데, 이는 내가 특정한 시험을 위해 두 개가 될 수있는 기본 설정을 얻는다.

Answer 4

나는이 방법으로 그렇게 할 것입니다. 왜냐하면 그 테스트에서 중요하며 엄격한 단위 테스트가 아닌 "외부"테스트에 의존하는 경우 엄격하게 보았 기 때문입니다.

Answer 5

적절한 문자열 리터럴을 지원하는 프로그래밍 언어를 사용하면 문제가 사라집니다. 예를 들어, 파이썬은 여러 문자열을 지원합니다

source = """ 
.presentInFileOne { 
} 

.presentInFileTwo { 
     bottom-corners-rounded : false; 
} 
.notUsed { 
} 
""" 

expected = """ 
.presentInFileOne { 
} 

.presentInFileTwo { 
     bottom-corners-rounded : false; 
} 
""" 

assert removeDeclaration(source, "notUsed") == expected 

이러한 언어 구조가 다른 것보다는 당신의 검사 결과를 읽기 쉽게 만들 것입니다.

Answer 6

multi-line Strings literals work in Java 해킹이 있습니다. 프로덕션에서는 성능을보고 싶지만 테스트에는 충분할 것입니다.

내 규칙 : 문자열이 작 으면 (< 10 줄) 인라인으로 유지하지만, 항상 밖으로 모든 것을 잘라내어 새 버전을 붙여 넣을 수있는 방식으로 인라인합니다. 필요한 경우 내 assertEquals()에서 문자열을 변환합니다.

문자열 리터럴이 더 길거나 더 복잡하거나 구문 강조 표시 등이있는 좋은 편집기를 사용하는 경우 테스트 이름과 함께 테스트 데이터 폴더에 파일 이름으로 저장하는 것이 좋습니다. 그런 다음 JUnit 테스트에서 getName()을 사용하여 문자열을로드하는 유틸리티 함수를 사용할 수 있습니다. 그러면 어떤 파일이 어떤 테스트에 속하는지 어떤 마법없이 알 수 있습니다.

많은 것을 가지고 있다면 테스트 클래스 이름 (class.getSimpleName())을 폴더 이름으로 사용하여 그립을 유지합니다.