단위 테스트에서 toString ()이 반환하는 문자열에 따라 반환 된 값을 테스트하는 것이 일반적으로 좋은 생각입니까?
예를 들어 다음을 수행하여 예상 목록이 반환되는지 확인합니다.
assertEquals(someExpression.toString() ,"[a, b, c]");
고려 사항은 다음과 같습니다.
장점 : 시간 절약 (실제 예상 값을 구성하려면 더 긴 코드가 필요함)
단점 : 테스트는 문서에 공식적으로 정의되어 있지 않은 toString ()에 의존하므로 향후 버전에서 변경 될 수 있습니다.
나는에 대한 테스트 것이 유일한 시간 toString()객체의 내가 구현하지 않은 편집 불가능한 클래스가있을 때이다 hashcode또는 equals하지만, 대신에 구현 된 toString()출력으로 해당 분야의 내용을. 그럼에도 불구하고 나는 동등성 테스트로 하드 코딩 된 문자열을 사용하지 않고 대신 다음과 같은 작업을 수행합니다.
SomeObject b = new SomeObject(expected, values, here);
assertEquals(a.toString(), b.toString());
귀하의 접근 방식은 처음에는 시간을 절약 할 수 있지만 장기적으로는 .NET Framework의 예상 결과 문자열을 하드 코딩하기 때문에 테스트를 유지하는 데 훨씬 더 많은 시간이 걸립니다 toString().
편집 1 : 당연히 문자열을 출력하는 함수 / 프로세스를 테스트하는 경우 예상 결과로 하드 코딩 된 문자열을 사용해야하는 시간 중 하나입니다.
String input = "abcde";
String result = removeVowels(input);
assertEquals(result, "bcd");
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다