Introduction to Android Testing – Part 3

In the previous two blog posts I covered how to get setup with testing in Android and we created a sample app that we will be continuing to develop in this blog post. If you missed those two posts, I suggest reading part 1 and part 2. Continue reading Introduction to Android Testing – Part 3

Retrofit 2 – Mocking HTTP Responses

In the previous post, I discussed implementing a custom Retrofit Client to mock out different HTTP response codes. This mechanism works well for Retrofit versions 1.9 and below but has its drawbacks. After trying out Retrofit 2, I have adjusted the previous sample and managed to achieve the same results (with some improvements 😀).

In order to test your android apps, one thing that normally gets frequently overlooked is the apps ability to handle different server responses. What if your server goes down for a while? Does your app fall over with it – or does it gracefully recover? Things like this are difficult to emulate with real servers, which is why mocking responses is such a great way to ensure your app is awesome.

In this example, we will look at creating an app that retrieves a quote of the day from a web service and displays it to the user. We will also add a failure mechanism to the front end to show the user a retry button if something goes wrong. We will also look at testing these failure mechanisms.

Example 1:

  1. Create a Rest Service interface that will be used with Retrofit.
  2. Ensure your activity calls the Retrofit Service that you have just created. In the code below, the service gets created and the activity asynchronously calls getQuoteOfTheDay() . When a successful response is received from the server, the quote is displayed otherwise a retry button is shown with an error message.
  3. You might wonder, how do we test that the retry button is properly shown when the server is down without turning the server off? 😁 Using Espresso and Retrofit MockWebServer we can easily achieve this. Create mock JSON and store it in your androidTest  folder.
    Success Response Sample JSON:

    404 Not Found Sample JSON:
  4. Below is the sample for testing the positive case (a quote is displayed to the user) and the negative case. A retry button is displayed to the user when the server is returning an error. You might want to do some other logic when there is an error but for simplicity we will just display a retry button.

    From the sample above, we can see that the method setUp() is starting up the MockWebServer and setting the BASE_URL  of the entire app to point to the local mock server’s url.
    The test testQuoteIsShown()  is enqueuing a 200 OK response on the mock server, with the JSON from the file we defined previously as the body. We then launch the Activity. Using Espresso, we ensure that the retry button is hidden and the quote is displayed.
    The test testRetryButtonShowsWhenError() does a similar thing, except it queues up a 404 response, ensures that the retry button is shown and that the text “Quote Not Found” is displayed.
  5. As you can see from the above sample, we have achieved the same results as the previous post, but using Retrofit 2.

Pros of testing this way:

  • Really simple to test different HTTP Status Codes
  • Not much code needed to emulate the different responses

Cons of testing this way:

  • Difficult to dynamically create the responses

Example 2:

In the sample app, I have also included another way to test your Rest API by implementing the interface defined at the very beginning.

  1. Create a mock implementation of your API methods. In this stub, we create a dummy quote and return that quote every time. This is defined in the androidTest folder.

    2. Create another mock implementation that will return the error scenario.

3. Create a test which will test the API response parsing.

As you can see, the implementation that we mocked out previously is now being used in the test. In the  setUp()  method the MockRetrofit object is created. This MockRetrofit object wraps around the dummy implementation that we created and emulates a network call by adding delays onto the calls.

The testRandomQuoteRetrieval()  uses the first mock implementation to test the positive scenarios, whereas  testFailedQuoteRetrieval()  uses the second mock implementation which will return a 404 error.

This can be used to test operations on the API and test front end scenarios such as adding items to the server without sending it off to the server unnecessarily.

Pros of testing this way:

  • Can create rich data to return to the tests which means testing can be more meaningful
  • Easy enough to set up
  • JSON isn’t static


  • Have to create new API implementations for different error scenarios
  • Hard to see from a glance what the API returns

I think a combination of the two mechanisms described above can definitely cover most scenarios that you would need to test in order to make your app stable. What are your thoughts?

You can check out the full project here on Github.

If you enjoyed this blog post – please consider buying me a cupcake!

No. of Cupcakes

Mocking API Responses using a Retrofit Client in Android (Retrofit 1.9)

Writing test cases in Android can be quite a daunting task, especially the handling of different server responses. Testing error responses can be quite problematic and your app might not cover all the different scenarios.

If you are using Retrofit 1.9 and below to do your network calls, testing error responses can be quite simple. There are a couple of ways to test Retrofit calls. In this post we will look at making the Client return different responses which are stored in .JSON files within the test project.

Firstly, create a  RetrofitMockClient within your test project that will replace your response with the custom responses that you define.

Create the response JSON for the service you wish to test. In this example, we will be testing a service that returns random quotes for a logged in user. The API call can have HTTP status codes such as 401 Unauthorised, 200 OK, 500 Internal Server Error etc.

For example, a 401 Unauthorised Response could look like this:   quote_401_unauthorised.json

These JSON files should be created and saved in the /androidTest/assets  folder.

Then create a test in the androidTest  folder:

There you have it, your custom Retrofit Client will now return the JSON that you have specified. Yay!

Pros of testing this way:

  • Simple & easy to understand.
  • Possible JSON response is stored within the test project – new developers will easily understand what the services are doing and what the expected server responses look like.
  • Easy way to test different response codes and how your app reacts to them.
  • It is also possible to test different returned headers with this mechanism.
  • No need to run a mocking web server.

Cons of testing this way:

  • Hard to test complex server responses (i.e. dates that should change dynamically based on current date).
  • Limited to the JSON that you define.
  • Hard to emulate network speed.

In the next post, we will look at using other mechanisms, like Mockito, for testing our APIs.

Code on Github