What's the actual use of 'fail' in JUnit test case?

后端 未结 8 1115
长情又很酷
长情又很酷 2021-01-30 15:31

What\'s the actual use of \'fail\' in JUnit test case?

相关标签:
8条回答
  • 2021-01-30 15:49

    In concurrent and/or asynchronous settings, you may want to verify that certain methods (e.g. delegates, event listeners, response handlers, you name it) are not called. Mocking frameworks aside, you can call fail() in those methods to fail the tests. Expired timeouts are another natural failure condition in such scenarios.

    For example:

    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 讨论(0)
  • 2021-01-30 15:51

    This is how I use the Fail method.

    There are three states that your test case can end up in

    1. Passed : The function under test executed successfully and returned data as expected
    2. Not Passed : The function under test executed successfully but the returned data was not as expected
    3. Failed : The function did not execute successfully and this was not

    intended (Unlike negative test cases that expect a exception to occur).

    If you are using eclipse there three states are indicated by a Green, Blue and red marker respectively.

    I use the fail operation for the the third scenario.

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

    1. Passed Case : a = new Interger(1), b= new Integer(2) and the function returned 3
    2. Not Passed Case: a = new Interger(1), b= new Integer(2) and the function returned soem value other than 3
    3. Failed Case : a =null , b= null and the function throws a NullPointerException
    0 讨论(0)
  • 2021-01-30 15:54

    I, for example, use fail() to indicate tests that are not yet finished (it happens); otherwise, they would show as successful.

    This is perhaps due to the fact that I am unaware of some sort of incomplete() functionality, which exists in NUnit.

    0 讨论(0)
  • 2021-01-30 15:57

    I've used it in the case where something may have gone awry in my @Before method.

    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
    }
    
    0 讨论(0)
  • 2021-01-30 15:59

    Let's say you are writing a test case for a negative flow where the code being tested should raise an exception.

    try{
       bizMethod(badData);
       fail(); // FAIL when no exception is thrown
    } catch (BizException e) {
       assert(e.errorCode == THE_ERROR_CODE_U_R_LOOKING_FOR)
    }
    
    0 讨论(0)
  • 2021-01-30 16:07

    The most important use case is probably exception checking.

    While junit4 includes the expected element for checking if an exception occurred, it seems like it isn't part of the newer junit5. Another advantage of using fail() over the expected is that you can combine it with finally allowing test-case cleanup.

    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);
    }
    

    As noted in another comment. Having a test to fail until you can finish implementing it sounds reasonable as well.

    0 讨论(0)
提交回复
热议问题