How to make a unit test for a method that is catching Exception.class?

Question

I am unit testing a class which is as below :

class ClassUnderTest {
    public SomeOtherClass var;
    public String methodUnderTest(){
        try {
            //call to some other method that throws CustomException
            String localvariable = var.someOtherMethod() //throws CustomException
            // generic operations on localvariable which can throw Exception
        } catch (CustomException e) {
            s.o.p(e);
        } catch (Exception e) {
            s.o.p(e);
        }

    }
}

The problem arises when I have to test the methodUnderTest for catching Exception.class. I can not mock SomeOtherClass to throw Exception as Exception is a checked exception and someOtherMethod throws only CustomException. How can I make a test case for this scenario ?

See: http://stackoverflow.com/questions/3762047/throw-checked-exceptions-from-mocks-with-mockito Your API is saying that the only checked exception that someOtherMethod will throw is `CustomException`. But then trying to throw a different checked Exception from the body. If you want to catch runtime exceptions (unchecked), then configure your mock to throw a `new RuntimeException()`, or add another checked Exception type (`Exception`) to the method signature. — Dave Lugg, Mar 17 '17 at 19:04
someOtherMethod throws CustomException. But the methodUnderTest does some generic operations after invoking someOtherMethod. It is here that the methodUnderTest is susceptible to an Exception like NPE or IndexOOB. I want to create a test for such scenario. If such a exception is raised, it is being caught. — Manas Shukla, Mar 17 '17 at 19:11
But those things donot throw checked exceptions, only runtime exceptions. You cannot test errors in code like that, unless you can feed it bad inputs (like making it divide by zero, or giving it a `null` reference). — john16384, Mar 17 '17 at 19:16
Thanks @john16384 I am a noob to Unit testing. Hence I am seeking to know as much as I can. Would it be a good practise to make a test case with bad inputs ? One obvious advantage that I get from such test case is that my coverage increases. But I don't want to increase the coverage, just for the sake of increasing it. Do these type of cases add quality to the TestClass ? — Manas Shukla, Mar 17 '17 at 19:17
To be honest, it is bad practice to catch exceptions you are not planning to handle (logging is not handling them). Things like a NPE or Division by zero, you should just let bubble up to a very high level (like the request level or user action level), and then handle them all there (by logging them and/or informing the user of a fatal error). If you catch those exceptions, what are you going to return as result? Something that makes sense or some garbage value that causes problems later on? — john16384, Mar 19 '17 at 20:21

score 2 · Answer 1 · answered Mar 17 '17 at 19:09

2

You donot show the signature of someOtherMethod, but if it doesn't declare any checked exceptions then it cannot throw any checked exceptions, so why test for them.

Just throw a RuntimeException to test the 2nd catch block instead.

answered Mar 17 '17 at 19:09

john16384

7,800
2
30
44

someOtherMethod throws CustomException. But the methodUnderTest does some generic operations after invoking someOtherMethod. It is here that the methodUnderTest is susceptible to an Exception like NPE or IndexOOB. I want to create a test for such scenario. If such a exception is raised, it is being caught. – Manas Shukla Mar 17 '17 at 19:14
NPE is a RuntimeException which isn't checked. – Dave Lugg Mar 19 '17 at 20:12

score 0 · Answer 2 · answered Mar 20 '17 at 16:31

The other exceptions you listed in your comment:

But the methodUnderTest does some generic operations after invoking someOtherMethod. It is here that the methodUnderTest is susceptible to an Exception like NPE or IndexOOB

Both NullPointerException and IndexOutOfBoundsexceptions are cases of the unchecked Exception type RuntimeException. You can throw an unchecked exception from your mock by instructing your mock to throw a new RuntimeException() (Depending on what mocking framework you're using, the usage will be different).

If you end up doing this, you should also modify your catch to catch RuntimeExceptions instead of Exceptions to be more clear about the intent of your try/catch block.

How to make a unit test for a method that is catching Exception.class?

2 Answers2