1. Introduction
In this article, we’ll go beyond the JMockit basics and we’ll start looking at some advanced scenarios, such as:
- Faking (or the MockUp API)
- How to mock more than one interface using only one mock
- How to reuse expectations and verifications
To discover JMockit’s basics, we can check other articles from this series. We can find relevant links at the bottom of the page.
2. Maven Dependency
First, we’ll need to add the jmockit dependency to our project:
<dependency>
<groupId>org.jmockit</groupId>
<artifactId>jmockit</artifactId>
<version>1.49</version>
</dependency>
Next, we’ll continue with the examples.
3. Protected Methods Mocking
Sometimes, we need to mock protected methods. With JMockit, we can use the MockUp API to alter the real implementation of protected methods.
All following examples will be done for the following class and we’ll suppose that are run on a test class with the same configuration as the first one (to avoid repeating code):
public class AdvancedCollaborator {
int i;
private int privateField = 5;
// default constructor omitted
public AdvancedCollaborator(String string) throws Exception{
i = string.length();
}
public String methodThatCallsProtectedMethod(int i) {
return protectedMethod() + i;
}
public int methodThatReturnsThePrivateField() {
return privateField;
}
private String protectedMethod() {
return "default:";
}
class InnerAdvancedCollaborator {...}
}
JMockit’s Mockup API provides support for the creation of fake implementations or mock-ups. Typically, a mock-up targets a few methods and/or constructors in the class to be faked, while leaving most other methods and constructors unmodified. JMockit allows for mocking up protected methods.
Let’s see how we can re-define protectedMethod() using the Mockup’s API:
public class AdvancedCollaboratorIntegrationTest {
@Tested
private AdvancedCollaborator mock;
@Test
public void testToMockUpProtectedMethod() {
new MockUp<AdvancedCollaborator>() {
@Mock
private String protectedMethod() {
return "mocked: ";
}
};
String res = mock.methodThatCallsProtectedMethod(1);
assertEquals("mocked: 1", res);
}
}
In this example, we’re defining a new MockUp for the AdvancedCollaborator class using the @Mock annotation on a method with a matching signature. After this, calls to that method will be delegated to our mocked one.
We can also use this to mock up the constructor of a class that needs specific arguments or configuration in order to simplify tests:
@Test
public void testToMockUpDifficultConstructor() throws Exception{
new MockUp<AdvancedCollaborator>() {
@Mock
public void $init(Invocation invocation, String string) {
((AdvancedCollaborator)invocation.getInvokedInstance()).i = 1;
}
};
AdvancedCollaborator coll = new AdvancedCollaborator(null);
assertEquals(1, coll.i);
}
In this example, we can see that for constructor mocking we need to mock the $init method. We can pass an extra argument of type Invocation, with which we can access information about the invocation of the mocked method, including the instance to which the invocation is being performed.
4. Private Fields Mocking
Mocking and testing of private fields is often not considered good practice.
The reasoning behind it is that if they’re private, they shouldn’t be tested directly as they’re the innermost guts of the class, but sometimes it still needs to be done, especially when dealing with legacy code.
With JMockit, we can use @Injectable annotation to mock up our private fields.
Let’s set a private field:
@Test
public void testToSetPrivateFieldDirectly(@Injectable("10") int privateField){
assertEquals(10, privateField);
}
And also get field:
@Test
public void testToGetPrivateFieldDirectly(){
assertEquals(5, mock.methodThatReturnsThePrivateField());
}
5. Mocking Multiple Interfaces in One Same Mock
Let’s assume that we want to test a class – not yet implemented – but we know for sure that it will implement several interfaces.
Usually, we wouldn’t be able to test said class before implementing it, but with JMockit we have the ability to prepare tests beforehand by mocking more than one interface using one mock object.
This can be achieved by using generics and defining a type that extends several interfaces. This generic type can be either defined for a whole test class or for just one test method.
For example, we’re going to create a mock for interfaces List and Comparator:
public class AdvancedCollaboratorIntegrationTest
interface IList<T> extends List<T> {}
interface IComparator extends Comparator<Integer>, Serializable {}
static class MultiMock {
IList<?> get() { return null; }
IComparator compareTo() { return null; }
}
@Test
public void testMultipleInterfacesWholeTest(@Mocked MultiMock multiMock) {
new Expectations() {
{
multiMock.get(); result = null;
multiMock.compareTo(); result = null;
}
};
assertNull(multiMock.get());
assertNull(multiMock.compareTo());
}
}
As we can see, we define a new static MultiMock class for the method test. That way, the MultiMock will be available as a type and we’ll be able to create mocks for it using JMockit’s @Mocked annotation.
If we need the multi-interface mock for a method, we can achieve this by defining the @Mocked annotation on the method signature and passing a new mock as the test method argument.
6. Reusing Expectations and Verifications
In the end, when testing classes, we may encounter cases where we’re repeating the same Expectations and/or Verifications over and over. To ease that, we can reuse both easily.
We’re going to explain it by an example (we’re using the classes Model, Collaborator, and Performer from our JMockit 101 article):
public class ReusingIntegrationTest {
@Injectable
private Collaborator collaborator;
@Mocked
private Model model;
@Tested
private Performer performer;
@Before
public void setup(){
new Expectations(){{
model.getInfo(); result = "foo"; minTimes = 0;
collaborator.collaborate("foo"); result = true; minTimes = 0;
}};
}
@Test
public void testWithSetup() {
performer.perform(model);
verifyTrueCalls(1);
}
protected void verifyTrueCalls(int calls){
new Verifications(){{
collaborator.receive(true); times = calls;
}};
}
final class TrueCallsVerification extends Verifications{
public TrueCallsVerification(int calls){
collaborator.receive(true); times = calls;
}
}
@Test
public void testWithFinalClass() {
performer.perform(model);
new TrueCallsVerification(1);
}
}
In this example, we can see in the setup() method that we’re preparing an expectation for every test so that model.getInfo() always returns “foo” and the collaborator.collaborate*()* always expect “foo” as the argument and returns true. We put the minTimes = 0 statement so no fails appear when not actually using them in tests.
Also, we’ve created the method verifyTrueCalls(int) to simplify verifications to the collaborator.receive(boolean) method when the passed argument is true.
Lastly, we can also create new types of specific expectations and verifications just by extending any of the Expectations or Verifications classes. Then we define a constructor if we need to configure the behavior and create a new instance of said type in a test.
7. Conclusion
With this installment of the JMockit series, we have touched on several advanced topics that will definitely help us with everyday mocking and testing.
We may do more articles on JMockit, so stay tuned to learn even more.
And, as always, the full implementation of this tutorial can be found over on GitHub.
7.1. Articles in the Series
All articles of the series: