# Our Android testing process

DevFeed: [Our Android testing process](<https://devfeed.tech/articles/our-android-testing-process-24579.md>)

Original publisher: [Read original article](<https://medium.com/headspace-engineering/our-android-testing-process-e055f1c7e15c?source=rss-3da90e297190------2>)

Author: Headspace

Published: 2022-06-22T05:16:52Z

Content type: article

Language: en

Sources: [Stories by Headspace on Medium](<https://devfeed.tech/sources/stories-by-headspace-on-medium.md>)

Topics: [Testing](<https://devfeed.tech/topics/testing.md>), [Android](<https://devfeed.tech/topics/android.md>), [unit test](<https://devfeed.tech/topics/unit-test.md>), [Mocking](<https://devfeed.tech/topics/mocking.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-testing](<https://devfeed.tech/tags/android-testing.md>), [firebase](<https://devfeed.tech/tags/firebase.md>), [junit](<https://devfeed.tech/tags/junit.md>), [mental-health](<https://devfeed.tech/tags/mental-health.md>), [mobile-app-development](<https://devfeed.tech/tags/mobile-app-development.md>), [mobile-test-automation](<https://devfeed.tech/tags/mobile-test-automation.md>), [mocking](<https://devfeed.tech/tags/mocking.md>), [quality-assurance](<https://devfeed.tech/tags/quality-assurance.md>), [test-lab](<https://devfeed.tech/tags/test-lab.md>), [testing](<https://devfeed.tech/tags/testing.md>)

## AI overview

Headspace describes its Android testing strategy after rewriting its app, including unit-test coverage standards, selective end-to-end testing, mocking, dependency injection, Robolectric, and Firebase Test Lab.

## Source excerpt

Our testing strategy, how we integrate it into our development workflow, and what the future holds for testing at Headspace. By John Qualls, Senior Software Engineer, Greg Rami, Principal Software Engineer, and Anton Gerasimenko, Software Engineer Introduction When we took on the daunting task of rewriting our entire app at the end of 2019, one of our key focus areas was testability. At the time, we had less than 20% of our code covered by unit tests -- no integration or end-to-end (E2E) tests -- and adding any tests to the code base was a big effort. From the beginning, we agreed on the standard of at least 80% unit test coverage on all Pull Requests (PRs), E2E tests for critical flows, and an architecture that was focused on testability. The result is a more robust codebase. Today, we're able to capture critical bugs via our tests suite coverage before they hit our users and, very importantly, it's now trivial, and very fast, to add new tests. Let's detail our testing strategy, how we integrate it into our development workflow, and what the future holds for testing at Headspace. Testing Strategy Shortly after the rewrite, we had hundreds of unit tests and around twenty E2E tests. We wanted to optimize the number of E2E tests that we do to only certain use cases where it makes sense to take on the additional time and costs in exchange for the reduced risk. Test selection pyramid for cost and speedUnit Tests Our unit tests are straightforward. They test a very small unit of code by relying on JUnit 5 and different layers of mocking: MockK to mock all the dependencies that are unrelated to the current test. This is made easier by using good architecture principles such as Single Responsibility Principle (SRP) and Dependency Injection (DI) We introduced a Java Faker library, that provides "fakes" for primitive values that do not need to have a specific value Similarly, we have our own "model Fakers" that provide domain objects. That way when the underlying classes chang