[java] JUnit 4 테스트에서 특정 예외가 발생했다고 어떻게 주장합니까?

tl; dr

• post-JDK8 : AssertJ 또는 커스텀 람다를 사용 하여 뛰어난 동작을 확인하십시오.

• pre-JDK8 : 오래된 good try– catchblock을 추천합니다 . ( 블록 앞에 어설 션 을 추가하는 것을 잊지 마십시오fail()catch )

Junit 4 또는 JUnit 5에 상관없이

긴 이야기

자신을 작성할 수 있습니다 그것을 스스로 할 try – catch블록 또는 JUnit을 도구 (사용 @Test(expected = ...)또는 @Rule ExpectedExceptionJUnit을 규칙 기능).

그러나 이러한 방법은 그다지 우아하지 않으며 다른 도구와 잘 가독성 이 좋지 않습니다 . 또한 JUnit 툴링에는 몇 가지 함정이 있습니다.

1. try– catch당신이 테스트 문제를 해결 블록을 작성하고 catch 블록의 주장을 작성해야 블록, 즉 미세하지만 많은 발견 할 수있다이 스타일은 인터럽트 테스트의 읽기 흐름을 그. 또한, 당신은 쓸 필요 Assert.fail의 끝 부분에 try블록. 그렇지 않으면 테스트에서 어설 션의 한쪽이 누락 될 수 있습니다. PMD , findbugs 또는 Sonar 는 이러한 문제를 발견합니다.

2. @Test(expected = ...)적은 코드를 작성하고이 테스트를 작성하는 것은 오류를 코딩 가정으로 적은 경향 수있는 기능은 흥미 롭다. 그러나 일부 지역에서는 이러한 접근 방식이 부족합니다.

   • 테스트에서 원인 또는 메시지와 같은 예외에 대한 추가 사항을 확인해야하는 경우 (예외 메시지가 중요하면 정확한 예외 유형이 충분하지 않을 수 있음)

   • 또한 테스트 코드 작성 방법에 따라 테스트 코드의 잘못된 부분에서 예외가 발생하여 거짓 양성 테스트가 발생할 수 있으며 PMD , findbugs 또는 Sonar 확신하지 못합니다 그러한 코드에 대한 힌트를 줄 것입니다.

     @Test(expected = WantedException.class)
     public void call2_should_throw_a_WantedException__not_call1() {
         // init tested
         tested.call1(); // may throw a WantedException
     
         // call to be actually tested
         tested.call2(); // the call that is supposed to raise an exception
     }

3. 이 ExpectedException규칙은 또한 이전 경고를 해결하려는 시도이지만, 예상 스타일을 사용하기 때문에 사용하기가 약간 어색하다고 생각합니다. EasyMock 사용자는이 스타일을 매우 잘 알고 있습니다. 일부에게는 편리 할 수 ​​있지만 BDD ( behavior Driven Development ) 또는 AAA ( Action Actassert ) 원칙을 따르는 경우 ExpectedException규칙이 해당 작성 스타일에 맞지 않습니다. 그 외에도 @Test예상 위치에 따라 방법 과 동일한 문제가 발생할 수 있습니다 .

   @Rule ExpectedException thrown = ExpectedException.none()
   
   @Test
   public void call2_should_throw_a_WantedException__not_call1() {
       // expectations
       thrown.expect(WantedException.class);
       thrown.expectMessage("boom");
   
       // init tested
       tested.call1(); // may throw a WantedException
   
       // call to be actually tested
       tested.call2(); // the call that is supposed to raise an exception
   }

   예상되는 예외도 테스트 문 앞에 놓여지며 테스트가 BDD 또는 AAA를 따르는 경우 읽기 흐름이 중단됩니다.

   또한 의 작성자 JUnit에 대한 이 주석 문제를 참조하십시오 ExpectedException. JUnit 4.13-beta-2 는이 메커니즘을 더 이상 사용하지 않습니다.

   풀 요청 # 1519 : Deprecate ExpectedException

   Assert.assertThrows 메소드는 예외를 확인하는 더 좋은 방법을 제공합니다. 또한 규칙의 순서가 중요하기 때문에 TestWatcher와 같은 다른 규칙과 함께 사용하면 ExpectedException을 사용하는 것이 오류가 발생하기 쉽습니다.

따라서 위의 옵션에는 모든주의 사항이 있으며 코더 오류에 영향을 미치지 않습니다.

4. 유망한 것으로 보이는이 답변을 만든 후에 내가 알게 된 프로젝트가 있습니다. 그것은 예외 입니다.

   프로젝트에 대한 설명에서 알 수 있듯이 코더는 유창한 코드 줄을 작성하여 예외를 포착하고 후자의 주장에 대해이 예외를 제공 할 수 있습니다. 그리고 Hamcrest 또는 AssertJ 와 같은 어설 션 라이브러리를 사용할 수 있습니다 .

   홈페이지에서 가져온 빠른 예 :

   // given: an empty list
   List myList = new ArrayList();
   
   // when: we try to get the first element of the list
   when(myList).get(1);
   
   // then: we expect an IndexOutOfBoundsException
   then(caughtException())
           .isInstanceOf(IndexOutOfBoundsException.class)
           .hasMessage("Index: 1, Size: 0")
           .hasNoCause();

   코드가 정말 간단 then하다는 것을 알 수 있듯이 특정 라인에서 예외를 포착하면 API는 AssertJ API를 사용하는 별칭입니다 (과 유사 assertThat(ex).hasNoCause()...). 어느 시점에서 프로젝트는 AssertJ의 조상 FEST-Assert에 의존했습니다 . 편집 : 프로젝트가 Java 8 Lambdas 지원을 양조하고있는 것 같습니다.

   현재이 라이브러리에는 두 가지 단점이 있습니다.

   • 이 글을 쓰는 시점에서이 라이브러리는 Mockito 1.x를 기반으로하며, 테스트 된 객체 뒤에 장면을 모방 한 것입니다. Mockito가 여전히 업데이트되지 않았으므로이 라이브러리는 최종 클래스 또는 최종 메소드와 함께 작동 할 수 없습니다 . 그리고 현재 버전의 Mockito 2를 기반으로 했더라도 글로벌 모의 메이커 ( inline-mock-maker) 를 선언해야합니다. 이 모의 메이커는 일반 모의 메이커와는 다른 단점이 있기 때문에 원치 않을 수도 있습니다.

   • 또 다른 테스트 종속성이 필요합니다.

   라이브러리가 람다를 지원하면 이러한 문제는 적용되지 않습니다. 그러나이 기능은 AssertJ 툴셋에 의해 복제됩니다.

   catch-exception 도구를 사용하지 않으려면 모든 것을 고려 하여 적어도 JDK7까지 try– catch블록 의 오래된 좋은 방법을 권장합니다 . JDK 8 사용자의 경우 AssertJ를 사용하는 것이 좋습니다. 예외를 주장하는 것 이상을 제공 할 수도 있습니다.

5. JDK8을 사용하면 람다는 테스트 현장에 들어가고 뛰어난 행동을 나타내는 흥미로운 방법으로 판명되었습니다. AssertJ는 유창한 유창한 API를 제공하여 예외적 인 행동을하도록 업데이트되었습니다.

   AssertJ를 사용한 샘플 테스트 :

   @Test
   public void test_exception_approach_1() {
       ...
       assertThatExceptionOfType(IOException.class)
               .isThrownBy(() -> someBadIOOperation())
               .withMessage("boom!");
   }
   
   @Test
   public void test_exception_approach_2() {
       ...
       assertThatThrownBy(() -> someBadIOOperation())
               .isInstanceOf(Exception.class)
               .hasMessageContaining("boom");
   }
   
   @Test
   public void test_exception_approach_3() {
       ...
       // when
       Throwable thrown = catchThrowable(() -> someBadIOOperation());
   
       // then
       assertThat(thrown).isInstanceOf(Exception.class)
                         .hasMessageContaining("boom");
   }

6. JUnit 5를 거의 완전히 다시 작성하면 어설 션이 약간 개선 되어 제대로 예외를 주장하는 즉시 사용 가능한 방법으로 흥미로울 수 있습니다. 그러나 실제로 어설 션 API는 여전히 약간 나쁘지만 외부에는 아무것도 없습니다 assertThrows.

   @Test
   @DisplayName("throws EmptyStackException when peeked")
   void throwsExceptionWhenPeeked() {
       Throwable t = assertThrows(EmptyStackException.class, () -> stack.peek());
   
       Assertions.assertEquals("...", t.getMessage());
   }

   알다시피 assertEquals여전히을 반환 void하고 AssertJ와 같은 체인 어설 션을 허용하지 않습니다.

   당신이 이름 충돌을 기억한다면 또한 Matcher또는 Assert와 같은 충돌을 만날 준비 Assertions.

오늘 (2017-03-03) AssertJ 의 사용 편의성, 검색 가능한 API, 빠른 개발 속도 및 사실상 테스트 종속성은 테스트 프레임 워크 (JUnit)에 관계없이 JDK8을 사용하는 가장 좋은 솔루션이라고 결론 내리고 싶습니다 여부), 이전의 JDK 대신에 의존한다 try–catch 그들이 투박한 느낌이 경우에도 블록.

이 답변은 동일한 가시성을 가지고 있지 않은 다른 질문 에서 복사되었습니다 . 저는 같은 저자입니다.

답변

public class FooTest {
  @Test
  public void doStuffThrowsIndexOutOfBoundsException() {
    Foo foo = new Foo();

    IndexOutOfBoundsException e = assertThrows(
        IndexOutOfBoundsException.class, foo::doStuff);

    assertThat(e).hasMessageThat().contains("woops!");
  }
}