java.lang.RuntimeException: Stub! in Android with Mockito

Question

I have been looking on Google for this error, and most of the answers I have found is to move junit dependence, to the top. Or use another mocking framework. I already moved the dependence and still fails, and the whole project uses mockito and powermock.

This is in resume, the code.

package co.pack.session;

import com.google.gson.JsonObject;
import org.junit.Test;
import co.pack.Session.Organization;
import static org.junit.Assert.assertEquals;

public class TestOrganization {

@Test
public void testLoadJson() {
    JsonObject json = new JsonObject();
    json.addProperty("theme_color", "red");
    Organization organization = new Organization();

    organization.loadFromJson(json);

    assertEquals("red", Organization.getThemeColor());
    }
}

Implementation

public static void loadFromJson(JsonObject json) {
    Organization.name = json.has("name") ? json.get("name").getAsString() : "";
    Organization.image = json.has("image") ? json.get("image").getAsString() : "";

    printActualOrganization();
}

private static void printActualOrganization() {
    Log.i(TAG, "_name_ " + name);
    Log.i(TAG, "_image_ " + image);
}

It fails on a Log line

Log.i(TAG, "_name_ " + name);

And got this

java.lang.RuntimeException: Stub!

at android.util.Log.i(Log.java:9)
at co.mobico.Session.Organization.loadJson(Organization.java:50)
at co.mobico.session.TestOrganization.testLoadJson(TestOrganization.java:28)

Log lines, never causes any error on my test, I don't know what is happening in this case.

It worked! But, I wish to remove robolectric from the project, do you know another way to make it work? Thank you. — Jimmy A. León, Jan 17 '17 at 20:06
You could wrap `Log` class in a new class (Logger for example). Then in your `Logger` class you could call the method `Log.i(...)`, in that way you can mock your class and avoid direct calls to Android APIs — Juan Cruz Soler, Jan 17 '17 at 20:48

Christopher · Answer 1 · 2017-01-18T09:03:20.387

6

You can try add the following options to your app build.gradle.

android {

    testOptions {
        unitTests.returnDefaultValues = true
    }
}

This should prevent you from getting this RuntimeException, because in this case the Android-Methods will return default values. Be aware that this might raise other problems, e.g. when using TextUtils.equals(...).

Basically I agree with the strategy to mock every dependency of your unit under test, but you can use the return values as a kind of workaround.

edited Jan 18 '17 at 09:03

answered Jan 18 '17 at 08:55

Christopher

7,900
4
38
63

Thank you! But, it's an old project with an old gradle version(1.0.+), and it doesn't have this property. And we didn't update it for too long, and now it's complicated to update it. – Jimmy A. León Jan 18 '17 at 20:48

score 1 · Answer 2 · answered Jan 17 '17 at 20:54

1

The problem is that you call a method directly on a mock.

You usually don't do that.

Usually you create a normal instance of your class under test (cut) and mocks for the dependencies it communicates with:

@Test public void exampleWithMocks(){
  // arrange
  DataTransferObject dto = new DataTransferObject();
  dto.setSomeProperty(SOME_PRIMITIVE_VALUE_OR_STRING);

  SomeServiceTheCutDependsOn dependency = mock( SomeServiceTheCutDependsOn.class);

  ClassUnderTest cut = new ClassUnderTest(dependency);

  // act
  Object result =  cut.doSomethingWith(dto);

  // assert
  assertThat(result,notNullValue());
  verify(dependency).expectedMethodCall(dto);
}

answered Jan 17 '17 at 20:54

Timothy Truckle

12,232
2
22
44

@GhostCat the reason is: you want to test the behavior of *your code*, not the mocking frameworks code... – Timothy Truckle Jan 18 '17 at 09:22
I mean: there are zero good reasons for a test method to call a mocked method. I find "usually" is already a too weak statement. – GhostCat Jan 18 '17 at 09:37
@GhostCat it *might* be usefull to test abstract classes with abstract methods if you refuse/cannot change to *composition over inharitance* – Timothy Truckle Jan 18 '17 at 09:42
1

@GhostCat `mock(AbstractClass.class, Mockito.CALL_REAL_METHODS)` but you will have to struggle with constructor injected dependencies, so I do not recomment it, just mentioning for the records... – Timothy Truckle Jan 18 '17 at 10:30
I changed the mock for a real instance of the object and still getting the same error. – Jimmy A. León Jan 18 '17 at 20:51
@JianLeón could you please add a [MCVE](http://stackoverflow.com/help/mcve) of both, the production class and the test class to your question? – Timothy Truckle Jan 18 '17 at 21:19
@TimothyTruckle Done! – Jimmy A. León Jan 18 '17 at 22:06

java.lang.RuntimeException: Stub! in Android with Mockito

2 Answers2