What\'s the actual use of \'fail\' in JUnit test case?
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");
}
This is how I use the Fail method.
There are three states that your test case can end up in
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())}
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.
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
}
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)
}
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.