Our approach to Testing with Android

In this blog post, I will introduce you to the strategies we defined to thoroughly test the Gousto Android App and go into detail about the different approaches we use for testing the different layers of our app.

Sep 5, 2018 · 4 min read

Architecture Overview

The Gousto Android App architecture is based on the well known Clean Architecture by Uncle Bob.

The Clean Architecture adapted to the Gousto android app
  • Domain: the business logic divided into use cases
  • Presentation: the UI (activities, fragment, views) and UI scenarios logic (presenters)

Testing Coverage Approach

In this section, I’ll describe our approach to testing different parts of the architecture. I’ll follow the framework goal - approach - coverage. The goal is what we are trying to achieve by testing a specific part of the architecture, the approach is how we decided to achieve the goal, and coverage is a brief overview of the components covered.

Data layer

This layer is mainly made of data source implementation and manipulation of data.

  • Give us the assurance the tests will fail if the data structure changes, isn’t processed in the same way or just can’t be manipulated anymore (after a refactor for example or a minor change in a request body)
  • Play a key role in describing our data manipulation rules.
  • Pure java unit tests running on the JVM for most of the suite and isolated robolectric unit tests for date source implementations based on Android framework components (SharedPreferences, SQLiteOpenHelper)
  • We mock the data source implementations when testing the repositories.
  • every database query
  • repositories
  • tiers modules (custom json serializer & deserializer, …)

Domain layer

This layer is made of use cases representing the business logic of the app

  • List and Describe the app functionalities and its business requirements
  • Pure java unit test running on the JVM
  • We mock only the repositories.
  • every mapper


Presenters are components of the presentation layer that follow a specific scenario with specific command. It collects & maps the data in an easy to display & logic-free view-model and triggers the UI to render it.

  • Pure java unit tests running on the JVM
  • Mocking of the use cases and mappers

User Interface

This is the end part of the presentation layer. It consists of any component visible to the customer + ui logic (ex: animation)

  • UI tests will run on a device with AndroidJunit runner. We mock the presetenters serving custom view-models
  • Fragments
  • View components

App Flows

End-to-end UI tests covering critical flows (Signup, Order Checkout, …). Only the network client is mocked and we control the state of the app with dummy JSON responses.

Bugs & Crashes

Unit tests are one of the way we tackle issues & crashes.

Legacy Code

Unit tests are also an excellent way to deal with legacy code.


  • Espresso: UI testing framework
  • Junit: Run unit tests on JVM instead of a device
  • AssertJ: to have nicer assertion, easily debuggable and to be more accurate on the expected behaviour of an assertion
  • Mockito: mocking & stubbing
  • Jacoco: to measure our test coverage
  • Roboletric:
    - to test implementations using exclusively android APIs (ex: SharedPreferences)
    - to test legacy code too tight to the android framework
Try Gousto on Android

Gousto Engineering & Data Science

Gousto Engineering Blog