Author: Thomas Keller

At work we’re heavily depending on Unit and Functional Testing for our current Android application. For Unit testing we’ve set up a pure Java-based project that runs on [Robolectric](http://pivotal.github.com/robolectric/) to provide a functional Android environment and we also added [Mockito](http://code.google.com/p/mockito/) to the mix to ease some code paths with spied-on or completely mocked dependencies. [Moritz Post wrote a comprehensive article](http://eclipsesource.com/blogs/2012/09/25/advanced-android-testing-with-roboguice-and-robolectric/) how to setup this – if you have some time, this is really worth a read.

Now our functional tests are based on what the Android SDK offers us – just that we’re using [Robotium](http://code.google.com/p/robotium/) as a nice wrapper around the raw instrumentation API – and until recently I thought it would not be possible to screw around much with an unaltered, but instrumented application on runtime. But while I was reading through [the Android Testing Fundamentals](http://developer.android.com/tools/testing/testing_android.html) I stumbled upon one interesting piece:

With Android instrumentation […] you can invoke callback methods in your test code. […] Also, instrumentation can load both a test package and the application under test into the same process. Since the application components and their tests are in the same process, the tests can invoke methods in the components, and modify and examine fields in the components.

Hrm… couldn’t that be used to just mock out the implementation of this one REST service our application uses? Yes, it could! Given the following implementation

@ContextSingleton
public class RequestManager {
    ...
    public <I, O> O run(Request<I, O> request) throws Exception {
        ...
    }
}

(where the `Request` object basically encapsulates the needed request data and Input / Output type information)

it was easy to create a custom implementation that would return predefined answers:

public class MockedRequestManager extends RequestManager {
    private Map<Request, Object> responses = new HashMap<Request, Object>();
    ...
    public <I, O> O run(Request<I, O> request) throws Exception {
        Object response = findResponseFor(request);
        if (response instanceof Exception) {
            throw (Exception) response;
        }
        return (O) response;
    }
    ...
    public void addResponse(Request request, Object response) {
        responses.put(request, response);
    }
}

Now that this was in place, the only missing piece was to inject this implementation instead of the original implementation. For that I created a new base test class and overwrote the `setUp()` and `tearDown()` methods like this:

public class MockedRequestTestBase extends ActivityInstrumentationTestCase2 {
    protected Solo solo;
    protected MockedRequestManager mockedRequestManager = new MockedRequestManager();
    ...
    private class MockedRequestManagerModule extends AbstractModule {
        @Override
        protected void configure() {
            bind(RequestManager.class).toInstance(mockedRequestManager);
        }
    }
    ...
    public MockedRequestTest() {
        super(MyActivity.class);
    }
    ...
    @Override
    protected void setUp() throws Exception {
        super.setUp();
        Application app = (Application) getInstrumentation()
            .getTargetContext().getApplicationContext();
        RoboGuice.setBaseApplicationInjector(
            app, RoboGuice.DEFAULT_STAGE,
            Modules.override(RoboGuice.newDefaultRoboModule(app))
                .with(new MockedRequestManagerModule()));
        solo = new Solo(getInstrumentation(), getActivity());
    }
    ...
    @Override
    protected void tearDown() throws Exception {
        super.tearDown();
        Roboguice.util.reset();
    }
}

It is important to note here that the module overriding has to happen _before_ `getActivity()` is called, because this starts up the application and will initialize the default implementations as they’re needed / lazily loaded by RoboGuice. Since we explicitely create a specific implementation of the `RequestManager` class before, the application code will skip the initialization of the actual implementation and will use our mocked version.

Now its time to actually write a test:

public class TestFileNotFoundException extends MockedRequestTestBase {
    public void testFileNotFoundMessage()
    {
        Request request = new FooRequest();
        mockedRequestManager.addResponse(
            request, 
            new FileNotFoundException("The resource /foo/1 was not found")
        );
        solo.clickOnView("request first foo");
        assertTrue(solo.waitForText("The resource /foo/1 was not found"));
    }
}

Thats it. Now one could probably also add Mockito to the mix, by injecting a spied / completely mocked version of the original RequestManager, but I’ll leave that as an exercise for the reader…

Have fun!