Terse Systems

I know enough about EasyMock now to feel very comfortable with it. I’ve even got an acronym for writing unit tests with EasyMock – SEREVA.

This breaks down to the following stages:

Setup the object under test with any required mocks.
Expect some methods on the mock to be called.
Replay the mock once all the expectations have been made.
Execute the object’s method when under test.
Verify the mock has had all its expectations met.
Assert the output of the method.

This basic framework takes care of most of the grunt unit tests.

But there’s more to mocking than that. There’s one particular gotcha I know about with EasyMock, and then there’s the horrible, nasty, no-good edge cases that you run into. Let’s start off.

Custom Argument Matching with Multiple Parameters

Let’s start off with the gotcha first. Say you’ve got a method like the following:

List findCarsByYearAndColor(Integer year, String color);

Say that you want to match year, but not color. You can’t say:

expect(carService.findCarsByYearAndColor(year, anyObject()).andReturn(null);

If you want to apply a custom argument matcher to either argument, you must apply it to both. So instead, you need to do this:

expect(carService.findCarsByYearAndColor(same(year), anyObject()).andReturn(null);

This is why same() exists.

Static and Final Methods

EasyMock does not allow you to mock static or final methods. EasyMock ClassExtension does not allow you to mock private methods or static classes. You can argue that such things should not exist, but we live an imperfect world where people don’t always think of our needs.

This means that dealing with final classes like java.net.URL or java.io.File are fiddly. But not impossible. There’s more than one way to skin this particular cat.

The by hand way is to use reflection: “final” is not final anymore. Heinz demonstrates how you can change final fields through several different versions of the JVM. This is a somewhat disturbing read, as it plays merry hell with my conception of what should and shouldn’t be possible in Java. But it’s there if you need it.

The snazzy way is to use JMockit, which is a small toolkit specifically designed to subvert the JVM. jMockit depends on the java.lang.instrument library, which is only available in JDK 1.5, but it provides functionality you can’t find anywhere else.

The alternative method is to say “if your code is hard to test, then your code is badly written.” While there may be a correlation, I think that what is ‘badly written code’ can only really be accurately be judged by a human being.

Private, Default or Protected Methods

jMockit is all over this.

Native methods

Don’t know.

Static or Final Classes

This is handled as above by reflection, or by jMockit.

Inner Classes

Don’t know. I suspect that anonymous inner classes are very tough. I believe that static inner classes should be accessible through jMockit, but haven’t checked.

Constructors

EasyMock 2.3 allows you to define a partial mock that will call a specified constructor. That’s good if you have something that needs to be passed into the object under test. So you can do:

public static abstract class A {
    public String s;

    protected A(String s) {
        this.s = s;
    }

    protected abstract int someMethod();
}

public void testFoo()
{
    Constructor cstr = A.class.getDeclaredConstructor(String.class);
    ConstructorArgs constructorArgs = new ConstructorArgs(cstr, "test");
    A a = createMock(A.class, constructorArgs, new Method[0]);
      
    foo.setA(a);
    expect(a.someMethod()).andReturn(0);
    replay(a);
    foo.execute();
}

If the object under testing needs to have a constructor mocked out, i.e.

public class Foo
{
    public Foo() { new File("c:\\boot.ini").delete() }

    public void methodToTest() { }
}

Then jMockit will replace non-default constructors. I don’t know of anything that will replace a default constructor.

Enums

As far as I can tell, there is no facility in EasyMock, EasyMock ClassExtension to mock out enum logic, as it is defined as final by the JVM. jMockit should be used here. And that’s it. jMockit looks like it’s branched out into integration tests as well, notably Hibernate. I know that Unitils is a competitor here, but haven’t played with either of them that much.