JUnit 테스트 케이스에서 '실패'의 실제 사용은 무엇입니까?


답변:


137

유용하다고 생각되는 몇 가지 경우 :

  • 불완전한 테스트를 표시하면 실패하고 완료 할 수있을 때까지 경고합니다.
  • 예외가 발생했는지 확인 :
try{
  // do stuff...
  fail("Exception not thrown");
}catch(Exception e){
  assertTrue(e.hasSomeFlag());
}

노트 :

JUnit4부터 예외가 발생하는지 테스트하는 더 우아한 방법이 있습니다. 주석 사용 @Test(expected=IndexOutOfBoundsException.class)

그러나 예외를 검사하려는 경우에도 작동하지 않으므로 여전히 fail().


5
실패와 예상되는 주석의 상대적인 장점에 대한이 블로그 게시물을 고려하십시오. blog.jooq.org/2016/01/20/…
lbalazscs

4
@sleske "예외를 검사하려면 여전히 fail ()이 필요합니다."-아니요. ExpectedException이 방법입니다. github.com/junit-team/junit4/wiki/exception-testing
kraxor

@kraxor : 사실, 내가 답을 썼을 때 그것에 대해 몰랐습니다 (아마도 그 당시에는 없었을 것입니다).
sleske

14

테스트중인 코드가 예외를 발생시켜야하는 -ve 흐름에 대한 테스트 케이스를 작성한다고 가정 해 보겠습니다.

try{
   bizMethod(badData);
   fail(); // FAIL when no exception is thrown
} catch (BizException e) {
   assert(e.errorCode == THE_ERROR_CODE_U_R_LOOKING_FOR)
}

10

일반적인 사용 사례는 부정적인 테스트에서 예외가 발생하지 않았을 때 호출하는 것입니다.

다음 의사 코드와 같은 것 :

test_addNilThrowsNullPointerException()
{
    try {
        foo.add(NIL);                      // we expect a NullPointerException here
        fail("No NullPointerException");   // cause the test to fail if we reach this            
     } catch (NullNullPointerException e) {
        // OK got the expected exception
    }
}

3
catch 블록에서 무언가를 확인하지 않으면 @ExpectedException (NullNullPointerException.class) 메서드 주석을 사용하여 예외 (특수 종류)를 예상한다고 선언 할 수 있습니다.
FrVaBe 2010

8

@Before 메서드에서 무언가 잘못되었을 수있는 경우에 사용했습니다.

public Object obj;

@Before
public void setUp() {
    // Do some set up
    obj = new Object();
}

@Test
public void testObjectManipulation() {
    if(obj == null) {
        fail("obj should not be null");
     }

    // Do some other valuable testing
}

1
예, 사전 조건을 테스트하는 것이 좋습니다. 그러나 @Before메서드가 성공 했는지 확인하려면 해당 메서드에서 직접 확인하는 것이 좋습니다. 보너스로 적어도 JUnit과 TestNG는 @Before/ @After메소드의 오류에 대해 다른 실패를보고 하므로 문제가 테스트 자체에 없었 음을 알 수 있습니다.
sleske

4

이것이 Fail 메서드를 사용하는 방법입니다.

테스트 케이스가 끝날 수있는 세 가지 상태가 있습니다.

  1. 통과 : 테스트중인 함수가 성공적으로 실행되었으며 예상대로 데이터를 반환했습니다.
  2. Not Passed : 테스트중인 함수가 성공적으로 실행되었지만 반환 된 데이터가 예상과 다릅니다.
  3. 실패 : 함수가 성공적으로 실행되지 않았으며 실행되지 않았습니다.

(예외가 발생할 것으로 예상되는 부정적인 테스트 케이스와는 달리).

eclipse를 사용하는 경우 세 가지 상태가 각각 녹색, 파란색 및 빨간색 마커로 표시됩니다.

세 번째 시나리오에서는 실패 작업을 사용합니다.

예 : public Integer add (integer a, Integer b) {return new Integer (a.intValue () + b.intValue ())}

  1. 통과 된 케이스 : a = new Interger (1), b = new Integer (2) 및 함수가 3을 반환했습니다.
  2. 통과되지 않은 경우 : a = new Interger (1), b = new Integer (2) 및 함수가 3이 아닌 값을 반환했습니다.
  3. 실패한 경우 : a = null, b = null 및 함수에서 NullPointerException 발생

1
JUnit의 소스 코드를 보면 어설 션이 fail().
Daniel C. Sobral

3

예를 들어, fail()아직 완료되지 않은 테스트를 표시 하는 데 사용 합니다. 그렇지 않으면 성공한 것으로 표시됩니다.

이것은 아마도 NUnit에 존재하는 불완전한 () 기능을 알지 못하기 때문일 것입니다.


2

동시 및 / 또는 비동기 설정에서 특정 메서드 (예 : 델리게이트, 이벤트 리스너, 응답 핸들러, 이름 지정)가 호출 되지 않았는지 확인할 수 있습니다. 모의 프레임 워크는 제쳐두고fail() 이러한 메서드를 하여 테스트에 실패 . 만료 된 시간 초과는 이러한 시나리오에서 또 다른 자연적인 실패 조건입니다.

예를 들면 :

final CountDownLatch latch = new CountDownLatch(1);

service.asyncCall(someParameter, new ResponseHandler<SomeType>() {
    @Override
    public void onSuccess(SomeType result) {
        assertNotNull(result);
        // Further test assertions on the result
        latch.countDown();
    }

    @Override
    public void onError(Exception e) {
        fail(exception.getMessage());
        latch.countDown();
    }
});

if ( !latch.await(5, TimeUnit.SECONDS) ) {
    fail("No response after 5s");
}

0

가장 중요한 사용 사례는 아마도 예외 검사입니다.

junit4에는 예외 발생 여부를 확인하기위한 예상 요소가 포함되어 있지만 새로운 junit5의 일부가 아닌 것 같습니다. 를 사용 fail()하는 또 다른 장점은 테스트 케이스 정리 expectedfinally허용 하는 것과 결합 할 수 있다는 것 입니다.

dao.insert(obj);
try {
  dao.insert(obj);
  fail("No DuplicateKeyException thrown.");
} catch (DuplicateKeyException e) {
  assertEquals("Error code doesn't match", 123, e.getErrorCode());
} finally {
  //cleanup
  dao.delete(obj);
}

다른 의견에서 언급했듯이. 구현이 끝날 때까지 테스트가 실패하는 것도 합리적으로 들립니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.