Testing Without a Mock Framework

What if I didn't use a mocking framework? I'll try testing a difficult piece of code with and without Mockito and see how it goes.

Here's the code:

import java.io.IOException;
import java.io.Writer;
import java.nio.charset.Charset;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;

public class HelloWorldFileWriter {

    void write() {
        try (Writer writer = this.createBufferedWriter()) {
            writer.write("Hello World!\n");
        } catch(IOException ex) {
            System.err.println("Problem with file system: " + ex.getMessage());
        }
    }

    Writer createBufferedWriter() throws IOException {
        Path file = Paths.get("/tmp/hello-world.txt");
        Charset charset = Charset.forName("US-ASCII");
        return Files.newBufferedWriter(file, charset);
    }
}

This writes a file to /tmp/hello-world.txt with the words "Hello World!" How can I isolate the test from the dependency on the file system? I don't want to go the route of constructor DI where I pass a BufferedWriter instance into the constructor because I should take advantage of Java's automatic resource management functionality in line 11.

Luckily, I don't have to go that route because I can test it anyway, but it still isn't easy, even with a mocking framework.

Using Mockito 2 and JUnit 5, I have to use a partial mock on the subject-under-test. That's because when the createBufferedWriter() method gets called, I supply my own mock instead, which prevents the test writing anything to the actual file system, but when the write() method gets called, I want the real method body to execute.

I end up with a test like this, which feels a bit weird:

@Test
public void testFileWriterWithMockito() throws Exception {
    Writer writer = mock(Writer.class);
    HelloWorldFileWriter helloWorldFileWriter = mock(HelloWorldFileWriter.class);
    when(helloWorldFileWriter.createBufferedWriter()).thenReturn(writer);
    doCallRealMethod().when(helloWorldFileWriter).write();
    helloWorldFileWriter.write();
    verify(writer).write("Hello World!\n");
}

What if I just use simple Java to test this? One way to do that is to create a child of HelloWorldFileWriter and override the createBufferedWriter() method, returning my own mock. That looks like this:

class HelloWorldFileWriterPartialMock extends HelloWorldFileWriter {

    FakeBufferedWriter writer;

    @Override
    Writer createBufferedWriter() throws IOException {
        this.writer = new FakeBufferedWriter();
        return this.writer;
    }
}

The FakeBufferedWriter class is going to capture the argument passed to the write method. So it needs to override the method and then store the contents of the passed-in String somewhere. I opt for a member named fileContents of String type.

class FakeBufferedWriter extends BufferedWriter {

    String fileContents;

    public FakeBufferedWriter() {
        super(new FakeWriter());
    }

    @Override
    public void write(String s) throws IOException {
        fileContents = s;
    }

}

class FakeWriter extends Writer {
    @Override
    public void write(char[] cbuf, int off, int len) throws IOException {
      // blank on purpose
    }

    @Override
    public void flush() throws IOException {
      // blank on purpose
    }

    @Override
    public void close() throws IOException {
      // blank on purpose
    }
}

One unfortunate artifact above is that the BufferedWriter class wraps another Writer instance. I had to create the FakeWriter class just to have a test double that doesn't actually write anything which could be passed in line 6. This was easy, though, because I just had my IDE generate the code for me.

With those few things in place, I now write a test:

    @Test
    public void testFileWriterWithMyOwnStubs() {
        HelloWorldFileWriterPartialMock helloWorldFileWriter = new HelloWorldFileWriterPartialMock();
        helloWorldFileWriter.write();
        assertEquals("Hello World!\n", helloWorldFileWriter.writer.fileContents);
    }

Pros and Cons

I am surprised to find that the test that doesn't use Mockito is actually easier to understand. It uses basic object-oriented principles which are readily supported in Java. It also wasn't that hard to think about how to create the test doubles and sub them in. On the other hand, I had to write (well, generate) more code when Mockito wasn't near at hand. That could be a good or a bad thing. It's probably good since the fakes are visible and I don't have to visualize what they're doing.

When I was writing the test with Mockito, I had to refer to the documentation because I almost thought maybe I should be using an ArgumentCaptor to capture the "Hello World!" String in the test, but of course I only needed the HelloWorldWriter to be a mock so I could assert on the call to write. Mockito dynamically uses reflection to create the equivalent result to my own fake objects. I have to know what Mockito is doing in order to visualize what is happening. It may not be as easy for someone to maintain the Mockito test in the future, depending on their familiarity with Mockito. Finally, Mockito is another dependency, and that adds its own maintenance responsibilities to the application.

Now, I'm not saying don't use a mocking framework. I am just saying perhaps using no mocking framework is a reasonable choice sometimes. I've used a number of Java mocking frameworks including JMock, EasyMock, and Mockito. Mockito is easily my personal favorite. For applications of some size, I don't really see myself ever going without a mocking framework. There are some things that are hard to test no matter what, usually things like this example where there are external dependencies.

But sometimes, every now and then, I like using an ad-hoc test double in the language itself, rather than creating one dynamically via a framework. I think mixing and matching mock framework usage with pure-language fakes definitely has its own advantages. If it's simpler to use a mocking framework, do that. If not, go with the mock framework.