How can I mock an auto closeable resource properly?

Question

I am trying to write a unit test for this:

try (final DatagramChannel channel = helper.createChannel()) {

...

}

In my test, I mock the helper (using Mockito), and tell helper.createChannel() to return a mocked channel.

This test fails with

java.lang.NullPointerException
at java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:111)

I understand that the try-with-resources facility in Java calls the close() method in the DatagramChannel upon exiting the try block, but shouldn't the close() method in the mocked DatagramChannel be called upon?

The debugger tells me that the closeLock in AbstractInterruptibleChannel is null.

Should I subclass the DatagramChannel, override the close() method in it, and then mock my subclass instead? Or, am I doing something wrong in a more profound way (the helper mock returns a mock)?

Regards, Fredrik Israelsson

Test code, upon request:

@Mock
private InetAddress peerAddress;
@Mock
private UDPChannelHelper helper;
@Mock
private DatagramChannel channel;

private UDPTransportImpl transport;

@Before
public void setUp() throws Exception {
    MockitoAnnotations.initMocks(this);
    when(helper.createChannel()).thenReturn(channel);
    transport = new UDPTransportImpl(peerAddress, 0, helper);
}

@Test
public void testNormalSubmit() throws Exception {
    transport.submit("Hello");
}

As you can see, I do not specify any behavior for channel.close(). I am under the belief that I should not have to, because close() returns void.

Answer 1

You are mocking a real class DatagramChannel, that extends AbstractInterruptibleChannel. However the AbstractInterruptibleChannel.close is final, and Mockito cannot currently mock final code. Which explains why you have an NPE in the code.

I must remind you that it is commonly accepted that mocking types you don't own is bad practice. I've seen people do it and they had bad surprises years later when the real implementation had changed, but the mock behavior didn't, so they wrongly thought everything was alright when they updated the version of the libraries.

Still if you want to continue this way because you have valid reasons for that (and there are some), you could return instead a mock of an interface, like Channel that actually extends Closeable. Or you can use any other interface that you need to interact with that were present in DatagramChannel. Also if you need more than one interface just use mock(Channel.class, withSetting().extraInterfaces(...)).

Hope that helps Cheers, Brice

Answer 2

I had the same problem and using spy(..) instead of mock(..) has worked for me. I was trying to simulate an error while truncating a file and my system was handling the error accordingly.

FileChannel fileChannel = spy(FileChannel.class);
mockStatic(FileChannel.class);
when(FileChannel.open(eq(filePath), eq(StandardOpenOption.WRITE))).thenReturn(fileChannel);
when(fileChannel.truncate(1000L)).thenThrow(new IOException("Unable to truncate file"));

...

// Snippet being tested!
fileChannel = FileChannel.open(filePath, StandardOpenOption.WRITE);
fileChannel.truncate(1000L); // Will throw the exception!

Answer 3

Keeping aside whether you should be doing this or not, one way you can work around this issue is by "fixing" the AbstractInterruptibleChannel mock instance (whether a FileChannel, a DatagramChannel, etc.) by providing an Object for the closeLock field used to synchronize the close call.

private static void fixChannelMock(AbstractInterruptibleChannel mockFileChannel) throws Exception {
    Field closeLockField = AbstractInterruptibleChannel.class.getDeclaredField("closeLock");
    closeLockField.setAccessible(true);
    closeLockField.set(mockFileChannel, new Object());
}

Be prepared to have to fix the above code on minor Java releases though as the internal implementation of AbstractInterruptibleChannel might change.