单元测试如何使用返回无效的方法来“测试合同”？

Question

Java 8 here but this is a general unit testing question that (is likely) language-agnostic.

The syntax of writing a JUnit test is easy, but deciding on what tests to write and how to test main/production code is what I find to be the biggest challenge. In reading up on unit testing best practices, I keep hearing the same thing over and over again:

Test the contract

I believe the idea there is that unit tests should not be brittle and should not necessarily break if the method's implementation changes. That the method should define a contract of inputs -> results/outcomes and that the tests should aim to verify that contract is being honored. I think.

Let's say I have the following method:

public void doFizzOnBuzz(Buzz buzz, boolean isFoobaz) {
    // wsClient is a REST client for a microservice
    Widget widget = wsClient.getWidgetByBuzzId(buzz.getId());

    if(widget.needsFile()) {
        File file = readFileFromFileSystem(buzz.getFile());

        if(isFoobaz) {
            // Do something with the file (doesn't matter what)
        }
    }

    return;
}

private File readFileFromFileSystem(String filename) {
    // Private helper method; implementation doesn't matter here EXCEPT...
    // Any checked exceptions that Java might throw (as a result of working)
    // with the file system are wrapped in a RuntimeException (hence are now
    // unchecked.

    // Reads a file from the file system based on the filename/URI you specify
}

So here, we have a method we wish to write unit tests for ( doFizzOnBuzz ). This method:

• Has two parameters, buzz and isFoobaz
• Uses a class property wsClient to make a network/REST call
• Calls a private helper method that not only works with the external file system, but that "swallows" checked exceptions; hence readFileFromFileSystem could throw RuntimeExceptions

What kinds of unit tests can we write for this that "test the contract"?

Validating inputs ( buzz and isFoobaz ) are obvious ones; the contract should define what valid values/states for each of those are, and what exceptions/results should occur if they are invalid.

But beyond that, I'm not really sure what the "contract" here would even be, which makes writing tests for it very difficult. So I guess this question really should be something like " How do I determine what the contract is for a unit test, and then how do you write tests that target the contract and not the implementation? "

But that title would be too long for a SO question.

Answer 1

Your code with the methods doFizzOnBuzz(Buzz buzz, boolean isFoobaz) and private File readFileFromFileSystem(String filename) is not easily testable, because the first method will try and read a file, and that's not something you want to do in test.

Here, doFizzOnBuzz needs something to provide a File for it to work with. This FileProvider (as I'll call it) could be an interface, something like:

public interface FileProvider {
  File getFile(String filename);
}

When running in production, an implementation to actually read the file from disk is used, but when unit testing doFizzOnBuzz a mock implementation of FileProvider could be used instead. This returns a mock File .

The key point to remember is that when testing doFizzOnBuzz , we are not testing whatever provides the file, or anything else. We assume that to working correctly. These other bits of code have their own unit tests.

A mocking framework such as Mockito can be used a create mock implementations of FileProvider and File , and to inject the mock FileProvider into the class under test, probably using a setter:

public void setFileProvider(FileProvider f) {
  this.fileProvider = f;
}

Also, I don't know what a wsClient is, bit I do know it has a getWidgetByBuzzId() method. This class too could be an interface, and for testing purposes the interface would be mocked, and return a mock Widget , similar to the FileProvider above.

With mockito, not only can you set up mock implementations of interfaces, you can also define what values are returned when methods are called on that interface: eg

//setup mock FileProvider
FileProvider fp = Mockito.mock(FileProvider.class);

//Setup mock File for FileProvider to return
File mockFile = Mockito.mock(File.class);
Mockito.when(mockFile.getName()).thenReturn("mockfilename");
//other methods...

//Make mock FileProvider return mock File
Mockito.when(fp.getFile("filename")).thenReturn(mockFile);

ClassUnderTest test = new ClassUnderTest();
test.setFileProvider(fp); //inject mock file provider

//Also set up mocks for Buzz,, Widget, and anything else

//run test
test.doFizzOnBuzz(...)

//verify that FileProvider.getFile() was actually called:
Mockito.verify(fp).getFile("filenane"); 

The above test fails if getFile() was not called with the parameter 'filename'

Conclusion If you cannot directly observe the results of a method, eg it is void, you can use Mocking to verify its interaction with other classes and methods.

Answer 2

The problem is that your contract method does not tell what effect you can observe from the outside. It is basically a BiConsumer, so appart from ensuring there is an exception or not, there is not much unit testing possible.

The test you could do is to ensure that the (Mocked) REST service is called, or that the File (part of the Buzz parameter, which might be pointing to a temporary file) will be impacted by the method under some conditions.

If you want to unit test the output of the method, you may need to refactor to separate the determination of what should be done (file needs update) from actually doing it.