Why does Mockito-inline’s MockedConstruction fail when mocking FileInputStream, and what’s the right way to handle this in legacy code?

General Discussions
1

Why does MockedConstruction throw “Could not initialize mocked construction” when mocking FileInputStream in Mockito-inline?

I’m trying to replace PowerMock with Mockito-inline’s MockedConstruction to mock object construction, specifically FileInputStream, because I cannot refactor the legacy code.

When I use MockedConstruction<FileInputStream> to mock the constructor in my test, I get:

org.mockito.exceptions.base.MockitoException: Could not initialize mocked construction

It seems related to the actual constructor running or resources being accessed during mock initialization. How can I properly mock FileInputStream construction with Mockito-inline, or is there a recommended alternative approach to testing legacy code that instantiates FileInputStream internally?

2

Having worked with a lot of legacy Java code over the years, I’ve learned that mocking core JDK classes, especially ones like FileInputStream almost always leads to trouble. Mockito-inline’s MockedConstruction fails here because FileInputStream does real native work during construction, and Mockito can’t safely intercept that. The cleaner approach is to wrap the file I/O.

Something like:

public class FileReaderWrapper {
    public InputStream open(String path) throws IOException {
        return new FileInputStream(path);
    }
}

And in tests:

FileReaderWrapper wrapper = mock(FileReaderWrapper.class);
when(wrapper.open(anyString()))
    .thenReturn(new ByteArrayInputStream("test".getBytes()));

It’s predictable, doesn’t touch the real filesystem, and works nicely with standard Mockito.

3

Yeah Ian, wrapping is definitely the safer long-term solution, and I’ve done the same in a lot of refactoring projects. But if you’re stuck with deep legacy code where you literally can’t introduce a wrapper, Mockito-inline just isn’t going to handle this case FileInputStream is too low-level.

In those situations, I’ve still seen teams fall back to PowerMock. It’s not ideal, but it does work because it can intercept constructor calls, even for classes like FileInputStream that Mockito-inline fails on.

PowerMockito.whenNew(FileInputStream.class)
    .withAnyArguments()
    .thenReturn(new ByteArrayInputStream("test".getBytes()));

Only use this when refactoring isn’t an option, but for legacy systems, it can be a temporary bridge.

4

Both of you make solid points. And building on that after spending years untangling tightly coupled legacy code, I’ve found that the most future-proof fix is to change the API itself. If your code doesn’t instantiate FileInputStream directly, you don’t need to mock constructors at all.

Something as simple as switching to dependency injection:

public void process(InputStream input) {
    // your logic here
}

Then your test becomes:

InputStream testStream =
    new ByteArrayInputStream("test".getBytes());
myClass.process(testStream);

No constructor mocking, no PowerMock, no tricky behavior just a clean testable design. It avoids Mockito-inline’s MockedConstruction limitations entirely.