Mocking Java InputStream Object

1. Introduction

InputStream is a common abstract class used for processing data. The data can originate from very different sources but using the class allows us to abstract from the origin and process it independently from a specific source.

However, when we write tests, we need actually to provide some solid implementation. In this tutorial, we’ll learn which of the available implementations we should choose or when it’s better to write our own.

2. InputStream Interface Basics

Before we jump into writing our own code, it’d be good for us to understand a little about how the InputStream interface is built. Fortunately, it’s pretty straightforward. To implement a simple InputStream, we only need to consider one method – read. It takes no parameters and returns the next byte of the stream as an int. If the InputStream has ended, it returns -1, signaling us to stop the processing.

2.1. Test Case

In this tutorial, we’ll test one method that processes text messages in the form of InputStream and returns the number of processed bytes. We’ll then assert that the correct number of bytes were read:

int bytesCount = processInputStream(someInputStream);
assertThat(bytesCount).isEqualTo(expectedNumberOfBytes);

What the processInputStream() method does internally is less relevant here, so we’re just using a very simple implementation:

public class MockingInputStreamUnitTest { 
    int processInputStream(InputStream inputStream) throws IOException {
        int count = 0;
        while(inputStream.read() != -1) {
            count++;
        }
        return count;
    }
}

2.2. Using the Naive Implementation

To better understand how InputStream works, we’ll write a simple implementation with a hardcoded message. Apart from the message, our implementation will have an index pointing to what byte of the message we should read next. Every time the read method is invoked, we’ll get one byte from the message and then increment the index.

Before we do that, we also need to check if we haven’t already read all the bytes from the message. If so, we need to return -1:

public class MockingInputStreamUnitTest {

@Test
public void givenSimpleImplementation_shouldProcessInputStream() throws IOException {
    int byteCount = processInputStream(new InputStream() {
        private final byte[] msg = "Hello World".getBytes();
        private int index = 0;
        @Override
        public int read() {
            if (index >= msg.length) {
                return -1;
            }
            return msg[index++];
        }
    });
    assertThat(byteCount).isEqualTo(11);
}

3. Using ByteArrayInputStream

If we are absolutely sure that the whole data payload will fit into the memory, the simplest choice is ByteArrayInputStream. We provide an array of bytes to the constructor, then the stream iterates through it, byte by byte, in a similar fashion to the example from the previous section:

String msg = "Hello World";
int bytesCount = processInputStream(new ByteArrayInputStream(msg.getBytes()));
assertThat(bytesCount).isEqualTo(11);

4. Using FileInputStream

If we can save our data as a file, we can also load it in the form of FileInputStream. The advantage of this approach is that data won’t be loaded into memory as a whole but rather read from the disk when needed. If we place the file in the resources folder, we can use a convenient getResourceAsStream method to create InputStream directly from a path in one line of code:

InputStream inputStream = MockingInputStreamUnitTest.class.getResourceAsStream("/mockinginputstreams/msg.txt");
int bytesCount = processInputStream(inputStream);
assertThat(bytesCount).isEqualTo(11);

Note that in this example, an actual implementation of the InputStream will be BufferedFileInputStream. As the name suggests, it reads bigger chunks of data and stores them in the buffer. Thus it limits the number of reads from the disk.

5. Generating Data on the Fly

Sometimes we want to test if our system works properly with a large amount of data. We could just use a big file loaded from a disk, but that approach has some serious drawbacks. It’s not only a potential waste of space, but version control systems like git aren’t made to play nicely with big binary files. Fortunately, we don’t need to have all the data beforehand. Instead, we can generate it on the fly.

To achieve that, we need to implement our InputStream. Let’s start with defining fields and constructor:

public class GeneratingInputStream extends InputStream {
    private final int desiredSize;
    private final byte[] seed;
    private int actualSize = 0;

    public GeneratingInputStream(int desiredSize, String seed) {
        this.desiredSize = desiredSize;
        this.seed = seed.getBytes();
    }
}

The “desiredSize” variable will tell us when we should stop generating data. The “seed” variable will be a chunk of data that will be repeated. Finally,  the “actualSize” variable will help us track how many bytes we have returned. We need it because we don’t actually save any data. We only return the “current” byte.

Using the variables we defined, we can implement the read method:

@Override
public int read() {
    if (actualSize >= desiredSize) {
        return -1;
    }
    return seed[actualSize++ % seed.length];
}

First, we check if we achieved the desired size. If we did, we should return -1 so the stream’s consumer knows to stop reading. If we didn’t, we should return one byte from the seed. To determine which byte it should be, we use the modulo operator to get the remainder of dividing the actual size of generated data by the length of the seed.

6. Summary

In this tutorial, we looked into how we can deal with InputStreams in tests. We learned how the class is built and what implementations we can use for various scenarios. Finally, we learned how to write our own implementation to generate data on the fly.