Java 8을 사용하면이 작업이 훨씬 쉬워지고 Kotlin / Scala는 두 배가됩니다.
우리는 작은 유틸리티 클래스를 작성할 수 있습니다
class MyAssertions{
public static void assertDoesNotThrow(FailingRunnable action){
try{
action.run()
}
catch(Exception ex){
throw new Error("expected action not to throw, but it did!", ex)
}
}
}
@FunctionalInterface interface FailingRunnable { void run() throws Exception }
그러면 코드가 간단 해집니다.
@Test
public void foo(){
MyAssertions.assertDoesNotThrow(() -> {
//execute code that you expect not to throw Exceptions.
}
}
Java-8에 액세스 할 수 없다면 고통스럽게 오래된 Java 기능을 사용합니다. 임의 코드 블록 및 간단한 주석
//setup
Component component = new Component();
//act
configure(component);
//assert
/*assert does not throw*/{
component.doSomething();
}
그리고 마지막으로, 최근에 사랑에 빠진 언어 인 kotlin과 함께 :
fun (() -> Any?).shouldNotThrow()
= try { invoke() } catch (ex : Exception){ throw Error("expected not to throw!", ex) }
@Test fun `when foo happens should not throw`(){
//...
{ /*code that shouldn't throw*/ }.shouldNotThrow()
}
이것을 어떻게 표현하고 싶은지를 정확하게 피할 수있는 여지가 많지만, 나는 항상 유창한 주장 의 팬이었다 .
에 관해서
당신은 이것에 잘못 접근하고 있습니다. 기능 만 테스트하십시오. 예외가 발생하면 테스트가 자동으로 실패합니다. 예외가 발생하지 않으면 테스트가 모두 녹색으로 바뀝니다.
이것은 원칙적으로는 정확하지만 결론에는 맞지 않습니다.
Java는 제어 흐름에 대한 예외를 허용합니다. 이는 Double.parseDoublea NumberFormatException및 a 를 Paths.get통한 API와 같은 API에서 JRE 런타임 자체에 의해 수행됩니다 .InvalidPathException .
Number 문자열의 유효성을 검사하는 구성 요소를 Double.ParseDouble작성했거나 Regex를 사용하거나 손으로 쓴 파서를 사용하거나 double 범위를 특정 항목으로 제한하는 다른 도메인 규칙을 포함하는 항목을 작성했다면이 를 테스트하는 가장 좋은 방법 구성 요소? 결과 문자열이 구문 분석 될 때 예외가 발생하지 않는다고 주장하는 확실한 테스트가 될 것이라고 생각합니다. 위 assertDoesNotThrow또는 /*comment*/{code}블록을 사용하여 해당 테스트를 작성합니다 . 같은 것
@Test public void given_validator_accepts_string_result_should_be_interpretable_by_doubleParseDouble(){
//setup
String input = "12.34E+26" //a string double with domain significance
//act
boolean isValid = component.validate(input)
//assert -- using the library 'assertJ', my personal favourite
assertThat(isValid).describedAs(input + " was considered valid by component").isTrue();
assertDoesNotThrow(() -> Double.parseDouble(input));
}
또한이 테스트를 input사용하여 Theories또는 Parameterized다른 입력에이 테스트를 더 쉽게 재사용 할 수 있도록 매개 변수화하는 것이 좋습니다 . 또는 이국적으로 가고 싶다면 테스트 생성 도구 를 사용 하십시오. )를 사용할 수 있습니다. TestNG는 매개 변수화 된 테스트를 더 잘 지원합니다.
내가 특히 동의하지 않는 것은 사용을 권장하는 것입니다 @Test(expectedException=IllegalArgumentException.class). 이 예외는 광범위하게 위험 합니다. 테스트중인 구성 요소의 코드가 변경되어 테스트에서 if(constructorArgument <= 0) throw IllegalArgumentException()해당 인수에 대해 0을 제공하는 것이 편리했기 때문에 테스트가 잘 이루어지고 테스트 데이터를 생성하는 것이 놀랍도록 어려운 문제이므로 매우 일반적입니다. 아무것도 테스트하지 않아도 녹색 막대가됩니다. 그러한 시험은 쓸모없는 것보다 더 나쁩니다.
