我应该如何对使用 google guava 库的代码进行单元测试，尤其是 io package 中的代码？

Question

A lot of the functionality in guava is provided by static methods. I haven't figured out how to merge the use of guava libraries and good Dependency Injection practice.

For example, if I were to use

Files.readLines(File, Charset)

then I find I have a hard time writing a unit test which doesn't touch the filesystem, which I only like to do for integration testing.

I guess it's possible that I could write an adapter for all of the ones I'm interested in? But that could possibly end up being a lot of work...

I find it odd that the guava libraries come from the same set of people that provide guice and write blog posts like this

Answer 1

Ugh, the dreaded static methods. I have heard that JMockit is capable of mocking out statics, but I've never tried it myself. The solution I typically use is an Adapter.

public class FilesAdapter {

    private final File file;

    public FilesAdapter( File file ) {
        this.file = file;
    }

    public List<String> readLines( Charset charset ) {
        return Files.readLines( file, charset );
    }
}

You can optionally have FilesAdapter implements an interface, although since this is a single purpose object, I typically wouldn't.

GUICE is capable of injecting concrete objects, and mocking frameworks such as JMock2 & Mockito are able to mock concretes as well. This is all a matter of academics and different people will have different opinions.

If you were using GUICE, you would wrap this guy in a factory for injection goodness.

public class FilesAdapter {

    private final File file;

    @Inject
    protected FilesAdapter( @Assisted File file ) {
        this.file = file;
    }

    public List<String> readLines( Charset charset ) {
        return Files.readLines( file, charset );
    }

    public interface Factory {
        FilesAdapter create( File file );
    }
}

Answer 2

We provided the common.io library as a stopgap until you finally get a real, proper filesystems API in JDK 7. That library will be interface-based and very testing-friendly.

Answer 3

Powermock allows you to mock static methods .

We're using it here and there, and I can testify that it works.

Answer 4

You can isolate the static dependency into it's own method (which can then be over-ridden for test purposes, as shown below). Usually, the isolated method would have 'protected' visibility.

import static org.junit.Assert.assertEquals;
import static org.mockito.Matchers.any;
import static org.mockito.Mockito.spy;
import static org.mockito.Mockito.when;

import java.io.File;

import org.junit.Before;
import org.junit.Test;

public class FileUtilsTest {

    private static final String[] TEST_LINES = { "test 1", "test 2", "test 3" };
    private static final File TEST_FILE = new File("/foo/bar");
    private FileUtils fileUtils;

    /**
     * Configure reusable test components
     */
    @Before
    public void setUp() {
        fileUtils = spy(new FileUtils());
        when(fileUtils.getLines(any(File.class))).thenReturn(TEST_LINES);
    }

    /**
     * Ensure the {@link FileUtils#countLines(File)} method returns the correct line count (without hitting the
     * file-system)
     */
    @Test
    public void testCountLines() {
        assertEquals(3, fileUtils.countLines(TEST_FILE));
    }

    /**
     * The class we want to test
     */
    public static class FileUtils {

        /**
         * Method that we want to test
         */
        public int countLines(final File file) {
            return getLines(file).length;
        }

        /**
         * Static dependency isolated to a method (that we can override, for test purposes)
         */
        public String[] getLines(final File file) {
            return Files.readLines(file);
        }
    }

    /**
     * Poorly written utility class with hard-to-test static methods
     */
    public static class Files {

        public static String[] readLines(final File file) {
            // In reality, this would hit the file-system
            return new String[] { "line 1" };
        }
    }

}

Answer 5

Provide your own stubs for the static methods you call and let the classloader 'inject' them for you.

In general, it's not really a problem to solve with DI and mocks. Some dependencies just aren't worth explicitly injecting if they're common enough to be assumed to be dependencies and you're confident enough that they work as advertised. I think Guava falls into this category. Likewise, mocks are great at eliding state manipulations, which static methods shouldn't be mucking around with anyway, so you're not going to gain much even if you manage to mock them out.

Answer 6

First of all, why not just let your unit tests touch the file system? Usually, reading small local test-specific files in a few tests adds no perceptible delay to the test run.

But if you really don't want to touch the file system, then simply mock it. For example, the following JMockit -based test should work:

@Test
public void someTest()
{
    new Expectations() {
        @Mocked Files files;
        @Input  List<String> lines = asList("Line 1", "Another line", "...");
    };

    // Called from code under test:
    List<String> lines = Files.readLines(someFile, charSet);
    // These "lines" will be the same as the "@Input" lines.

    // asserts...
}