Is there a way to verify if the Catch part of a try/catch instruction is called in a test method when using JUnit?

Question

For example, if I had the following class that I want to test:

public class SomeClass{
    public void someMethod() {
        try {
            //Some code, where comething could go wrong
        } catch (Exception err) {
            //Handling it amounts to logging the problem and trying to continue
        }
    }
 }

If I then test this method with JUnit, then if something does go wrong in the try clause and the catch code is run, then the test will pass.

I want to make it so that the test will fail if the catch clause instructions are run.

I did think of a few ways I could try and write tests so that I get an equivalent sort of functionality, but there are reasons for each one that I do not want to approach it that way. It seems like trying to fail the test if any catch clause is reached is the cleanest way to do this, if that is in fact possible

Notes:

I know I could verify certain features of the code and check if they are a certain value/have been run a number of times with Mockito. However I want a solution where if changes were made to the test method that radically altered how it worked (but not what task was essentially being carried out) then I won't have to rewrite the test.

Unfortunately, just to make this proble more difficult, I am unable to make any modifictions to the source code. This position is out of my control so I have to work within these confines.

---

EDIT:

SomeClass is the class that I wish to test. It is not the actual JUnit test. I have edited my original question to try and clarify this.

Answer 1

I've had to deal with this sort of problem before. I ended up mocking the logging sub-system (not simple but not overly complex) and listened for the 'interesting' logging calls, and then flagging failures when it happened.

Answer 2

Remember that you are testing the behavior of this function. Your test should not care (so not test) that an exception is caught, just that the behavior you want happens.

This means that if you want to test that something is (or isn't) logged. Then you have to verify somethings is logged. In several of my applications I have made a distinction between debug logging and important logmessage. The latter we send through a class (in our case we used the Facade design pattern). that we can mock (and thus test the calls). For most applications, much of the developer logging does not have to be tested, so in those cases you should ignore that.

Answer 3

I don't know of any framework which let you assert exceptions were thown and handled in the method and not propagated. From the problem description I'd see two approaches, both using BDD:

1. Assert a line of code inside the catch block is not invoked - the logger would be a good option as @Thirler suggests
2. Assert the Exception constructor is not invoked

Both have problems:

1. Not very clean as you desire because it is tightly coupled to the actual code being executed.
2. Any exception handled in the code will trigger a failure.

You could try using aspectj to instrument the code and flag that an exception has been thrown while executing SomeClass.someMethod .

Answer 4

In a general way,

-1- Checking that some function f() throws an exception

try {
  f();
  // notify test failure here
} catch (...) {
  // success
};

-2- Checking that it doesnt

try {
   f();
} catch(...) {
   // notify test failure here
}

Answer 5

you may consider using assert

what is assert you may ask:

An assertion is a statement in the JavaTM programming language that enables you to test your assumptions about your program. For example, if you write a method that calculates the speed of a particle, you might assert that the calculated speed is less than the speed of light.

I'm not going through the details as I couldn't explain it better than its own documentations.