Fixing Upgrade Mockito 1.x to 2.x issues

With Kotlin in place, in order to support Mocking Kotlin class without opening it, we would require Mockito 2.0. Check out on the detail. In migrating from Mockito 1 to Mockito 2, faced two issues that need some exploration before one could solve it. Hence shared it here. my blog Note: In our scenario here, the below is used testCompile "org.mockito:mockito-inline:2.8.47" 1. Distinguish of Null and Non-Null item In Mockito 1.x, when we are of define scenario of any argument, we would just typed it accordingly such as verify when when(myMock.myBoolean(Mockito.any(MyClass.class)).thenReturn(true); verify(myMock).myFunction(Mockito.any(String.class)); //or in some case verify(myMock).myFunction(Mockito.anyString()); When you migrate over to Mockito 2.x, this still works without compile warning. However when you run, some test will start failing. This is because, now for is defined to be explicitly needing object that is Non-Null. If a null is passed in instead, it will fail the matching. any(Class Type) T So to overcome this issue, as per stated by , use this below Mockito Issue when(myMock.myBoolean(Mockito. any()).thenReturn(true); verify(myMock).myFunction(Mockito. any()); This will allow both the Null and NonNull matching. Well, you might only want to do this if this is really a nullable argument. 2. Inability to Mock Some class no longer mockable. One most distinct example is . The error as below. FirebaseRemoteConfig org.mockito.exceptions.base.MockitoException: Mockito cannot mock this class: class com.google.firebase.remoteconfig.FirebaseRemoteConfig. If you’re not sure why you’re getting this error, please report to the mailing list. Java : 1.8 JVM vendor name : JetBrains s.r.o JVM vendor version : 25.152-b01 JVM name : OpenJDK 64-Bit Server VM JVM version : 1.8.0_152-release-915-b01 JVM info : mixed mode OS name : Mac OS X OS version : 10.12.6 You are seeing this disclaimer because Mockito is configured to create inlined mocks. You can learn about inline mocks and their limitations under item #39 of the Mockito class javadoc. It is reported in , and is still open. Mockito Issue The way to workaround this, is to wrap the class with an Interface Helper class. Hence if you are originally mocking @Mock FirebaseRemoteConfig firebaseRemoteConfig; Now you could @Mock FirebaseRemoteConfigHelperInterface firebaseRemoteConfig; The implementation interface could just wrap around the actual object, and implement only those function that it uses. e.g. FirebaseRemoteConfig public class FirebaseRemoteConfigHelperImpl implements FirebaseRemoteConfigHelperInterface { private FirebaseRemoteConfig firebaseRemoteConfig public FirebaseRemoteConfigHelperImpl( FirebaseRemoteConfig firebaseRemoteConfig) { this.firebaseRemoteConfig = firebaseRemoteConfig } // Follow by all the implementation function of // firebaseRemoteconfig used } With that, this is now mockable. It is not an ideal solution, but there shouldn’t be too many of such classes is un-mockable. So we’ll live with that, but I’m open for better solution idea to be shared. If you like my post and want to get future update, follow me at ~ medium Twitter:elye ; Facebook:elye