btaz

This is a somewhat confusing compilation failure that sometimes happen when you write unit tests using JUnit 4. This is an example code snippet that produces this error (result.getValue() returns an Integer object):

assertEquals(12345, result.getValue());

And when you try to compile your project it produces a compilation error like this:

/projects/myapp/src/test/java/org/myapp/MyTest.java:[88,8] reference to assertEquals is ambiguous, both method assertEquals(double,double) in org.junit.Assert and method assertEquals(java.lang.Object,java.lang.Object) in org.junit.Assert match

Since JUnit offer several methods that are very similar the compiler can not always determine which one to use. In our case we have the number 12345 which is an int and result.getValue() which is an Integer. You’d think that the compiler could figure out to convert the number 12345 to an Integer object which would give us a match on “assertEquals(java.lang.Object, java.lang.Object) method, but instead it throws the above error.

The reason for this is that Java uses best match to try to determine the method that will require the least conversion of the parameters. In this case one method requires boxing, and the other method would require un-boxing. Both of these methods have equal priority and that’s why there is ambiguity since none of the methods are more specific than the other.

The solution is to help the compiler determine what it need to do. We can do that using this:

assertEquals(12345, (int) result.getValue());

or this:

assertEquals((Integer)12345, result.getValue());

to resolve this problem. The second solution that converts 12345 to an Integer object is most likely the better once since Java will auto-box a null value to the number 0 which may not be the correct behavior for the class you’re testing.

I’ve used JMock for quite some time and I’ve found it to be a great and very useful mocking framework for unit testing. I was never quite happy with the syntax though; especially the part where you specify expectations.  Here’s a JMock snippet illustrating an expectation and a return value from a mocked object

context.checking(new Expectations() {{
    oneOf (department).employees(); will(returnIterator(employees));
}});

In Mockito the equivalent code would look like this

when(department.employees()).thenReturn(employees);

I find the Mockito syntax to be easier to write and understand. I’ve seen fellow developers implement JMock expectations in a way where they actually didn’t perform a useful test, and I think the sometimes confusing syntax of JMock was the reason. I’m not dismissing JMock as an inferior mocking framework, but I do think that the learning curve is a bit steeper. If you haven’t used Mockito yet I encourage you to take a look at it.