Is this an acceptable way of writing JUnits or a simple a bad practice ?

[Monica Shiralkar]

In some JUnit codes I have seen that if one has to test some method, instead of actually testing by asserting that the method returns the expected out , one simply does like below :

try
{
someMethod(arg1, arg2, arg3);

}
catch (Exception e)
{
Assert.fail();
}

Seeing such code, I feel although it doesn't test the actual thing, it partially serves the purpose.

Is this acceptable practice or simply a bad practice ?

Thanks.

[Rob Spoor]

I regard that as a bad practice, especially if the exception is ignored. With this code, the test fails without any reason. If the exception is simply thrown (so without the try-catch), the test will fail with an error, and the exception will be available.

The other way around is more interesting:

try {
    runCodeThatShouldFail();
    Assert.fail("code should have failed");
} catch (ExpectedExceptionType e) {
    // ignore, or assert
}

I've used this quite a lot in the past. However, since JUnit 4.13 and JUnit 5, this is no longer needed. Instead, assertThrows can be used:

ExpectedExceptionType thrown = assertThrows(ExpectedExceptionType.class, () -> runCodeThatShouldFail());
// assertions on thrown can be added
// if no assertions are wanted, just omit the variable

There are some warnings about that though - the code inside assertThrows should preferably have only one method call. That way, you know which method triggers the exception. (I've had Sonar complain many times if I used more than one method call).

[Tim Holloway]

Yes, anything that throws away an Exception message when it doesn't even know what the Exception is is VERY bad practice regardless of whether it's in test code or mainline code. And those who do it where I can catch them should be prepared to face dire consequences.

[Monica Shiralkar]

Yes, anything that throws away an Exception message when it doesn't even know what the Exception is is VERY bad practice

This is first reason. I think the second reason for it to be bad code is that just absence of exception thrown doesnt mean code is working fine.

[Rob Spoor]

Very true.