PunCha PunCha - 4 months ago 14
Java Question

Failed to mock ArrayList with option, CALLS_REAL_METHODS

According to the official doc: http://site.mockito.org/mockito/docs/current/org/mockito/Mockito.html#CALLS_REAL_METHODS

I wrote the following test:

package tk.puncha.study;

import org.junit.Test;

import java.util.ArrayList;

import static org.mockito.Mockito.*;

public class MockitoTest {

@Test
public void test() {
ArrayList arrayList = mock(ArrayList.class, withSettings().defaultAnswer((CALLS_REAL_METHODS)));
arrayList.add(new Object());
}
}


But it crashes with the following exception:

java.lang.NullPointerException
at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:234)
at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:227)
at java.util.ArrayList.add(ArrayList.java:458)
at tk.puncha.study.MockitoTest.test(MockitoTest.java:16)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:119)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)


Is it a JUnit bug or I'm wrong?

Answer

Using a mock with a CALLS_REAL_METHODS default answer is dangerous. Mockito doesn't initialize your mocked object's fields to be realistic (non-null), so real methods will interact with invalid fields and cause errors like the one you're seeing.

Here, ArrayList.ensureExplicitCapacity accesses elementData.length on what must be a null elementData array, leading to your error.

If you used a spy instead, which defaults to CALLS_REAL_METHODS behavior, Mockito would copy over the field values from an actually-constructed object instance you provide. This is generally safer.

(Side note: Outside of toy examples, remember that it's dangerous to mock types you don't own, and that there's almost never a reason to mock simple well-tested library objects like List or its implementations.)

Comments