0

I have a situation where I'm fairly certain exceptions will not occur. However, due to the design of the APIs consumed, I must account for them anyway. In the unlikely case these exceptions are thrown, I will be throwing a RuntimeException that will bubble up to the UI. Here's a simple case:

public class SomethingUsingJaxB{
   private JAXBContext jaxbContext;

   public SomethingUsingJaxB(){
      try{
          jaxbContext = JAXBContext.newInstance(Input.class);
      }catch(JAXBException e){
          throw new RuntimeException(e);
      }
   }

   public Output getOutput(Input input){
      //Do stuff with jaxbContext that also throws checked exceptions;
   }
}

In the full version of this class, I also have a TransformerFactory, Templates, and DocumentBuilderFactory which all throw checked exceptions, AND these factories return objects which themselves throw checked exceptions. I can't think of any situation where these exceptions are actually going to be thrown, but I'd like unit tests to account for them anyway.

Is there a "clean" way of unit testing these that doesn't heavily involve mocking frameworks?

Christopher Schneider
  • 3,745
  • 2
  • 24
  • 38
  • 1
    It depends on what you mean by "heavily involve mocking frameworks". PowerMockito [makes it easy](http://stackoverflow.com/questions/21105403/mocking-static-methods-with-mockito) to mock a static method. However, since the `catch` is simply wrapping and throwing as an unchecked exception, is it even worth the effort? Don't do it just because a manager wants to see higher code coverage! – Andrew S Feb 08 '17 at 17:47
  • There's nobody mandating this. I don't want someone to inadvertently change the behavior and swallow these exceptions. Will see if PowerMockito has some methods to handle this nicely. – Christopher Schneider Feb 08 '17 at 19:00

0 Answers0