Part 2: Types of Android Tests – Unit, UI, Integration & End-to-End

 Understand the purpose, tools, and trade-offs of each test type before you write a single line of code.

Introduction

Before writing your first test, you need to understand the different types of tests available — and when to use them.

This post will walk through the four major categories of Android tests:

  1. Unit Tests

  2. UI Tests

  3. Integration Tests

  4. End-to-End (E2E) Tests

Each test has a purpose. And knowing when not to use one is just as important as knowing when to use it.

Why This Matters

  • If you only write UI tests, your tests will be slow and fragile.

  • If you only write unit tests, you’ll miss how features interact.

  • If you don’t test at all — you’re flying blind.

A good Android test suite balances speed, confidence, and coverage. That’s where the test pyramid comes in.

The Android Testing Pyramid

        UI Tests (Espresso)
     Integration Tests (Fakes)
    Unit Tests (JUnit, Mockito)

  • Unit Tests are fast, small, and easy to maintain. Write lots of these.

  • Integration Tests combine multiple classes or layers. Use these to catch edge cases across layers.

  • UI Tests verify real user interactions. Write a few key ones, but keep them lean.

1. Unit Tests

Purpose

Test logic in complete isolation, without any Android framework dependencies.

Examples

  • ViewModel logic

  • Use cases

  • Validation functions

  • Mapper classes

Tools

  • JUnit

  • Mockito

  • Kotlin Coroutines Test

  • Truth / AssertJ (optional)

Pros

  • Fast

  • Reliable

  • Easy to write and maintain

When not to use

  • When you need to test screen behavior or navigation

  • When your logic heavily depends on Android components (unless abstracted)

2. UI Tests (Instrumentation Tests)

Purpose

Test real user flows through the actual app on a device or emulator.

Examples

  • Button clicks and navigation

  • Text input and validation

  • Screen transitions

  • Toasts, dialogs, snackbars

Tools

  • Espresso

  • AndroidX Test

  • UI Automator (advanced cases)

Pros

  • High confidence

  • Tests what the user sees

  • Verifies accessibility and flows

Cons

  • Slow to run

  • Can be flaky without idling resources

  • Expensive to write and maintain in large numbers

3. Integration Tests

Purpose

Test how multiple parts of your app work together, usually with fake dependencies.

Examples

  • ViewModel + UseCase + FakeRepository

  • Repository + DAO

  • Interactor + NetworkClient

Tools

  • JUnit

  • Mockito / Fake classes

  • Hilt Test modules

  • Robolectric (in some cases)

Pros

  • Tests real data flow without relying on the full stack

  • More confidence than isolated unit tests

  • Still relatively fast

Cons

  • Requires test setup and careful mocking/faking

  • Can blur boundaries if not scoped correctly

4. End-to-End (E2E) Tests

Purpose

Test an entire user scenario from start to finish, touching real or mocked backend, UI, and data layers.

Examples

  • Login → dashboard → logout

  • Add item to cart → checkout

  • Offline scenario testing

Tools

  • Espresso

  • Retrofit with fake API layer or MockWebServer

  • Navigation testing APIs

Pros

  • Simulates real user behavior

  • Catches system-wide bugs

  • Excellent for critical flows

Cons

  • Slowest and hardest to maintain

  • Requires complete environment setup

  • Should be limited to key use cases

Summary: When to Use What

Goal Test Type
Test logic (fast, isolated) Unit Test
Test multiple layers with fakes Integration Test
Test screen UI and user interactions UI Test (Espresso)
Test real-world user scenarios End-to-End Test

Example Scenario: Login Feature

Test Type What to Test
Unit Test ViewModel: isValidEmail, submitLogin(), loading state
Integration ViewModel + FakeRepository: successful and failed login
UI Test Input email & password, tap Login, see next screen
E2E Full login process using test server, then verify dashboard state

Interview Questions & Answers

Q1. What is a unit test?
A test that checks individual components (functions/classes) in isolation from other parts of the app.

Q2. What’s the difference between UI test and instrumentation test?
UI tests are a subset of instrumentation tests. Instrumentation tests run on device; UI tests use tools like Espresso to simulate user actions.

Q3. Why not write only UI tests?
UI tests are slower, flakier, and more costly to maintain. Unit and integration tests are faster and provide quicker feedback during development.

Q4. What’s the benefit of integration testing?
It ensures that components communicate correctly — for example, a ViewModel calling a Repository — without depending on full UI or backend.

Q5. Should you use real backend in end-to-end tests?
Ideally no — use mock servers like MockWebServer to simulate backend behavior so tests are reliable and repeatable.

Q6. How do you test navigation between screens?
Use Espresso along with FragmentScenario or NavigationTesting APIs to simulate navigation and assert destination.

Q7. What test types would you use for a shopping cart feature?

  • Unit: price calculation logic

  • Integration: cart ViewModel + local DB

  • UI: add to cart flow

  • E2E: full checkout process with payment mock

Q8. Is it okay to skip testing trivial UI elements?
Yes. Focus your effort on high-value paths and logic that’s likely to break. Don’t over-test simple Android components.

Coming Up Next

In Part 3, we’ll set up your testing environment in Android Studio, including:

  • Adding test dependencies

  • Creating your first unit test

  • Folder structure and best practices

  • Writing your first assertion

This will be your first hands-on session.

Help Support This Series

If this post helped you:

  • Follow this blog to get notified of the next part

  • Bookmark the Series Index to keep track

  • Leave a comment if you want help, feedback, or a specific topic covered

  • Share with developers learning Android testing


Comments

Post a Comment

Popular posts from this blog

Jetpack Compose based Android interview and questions

What’s Jetpack Compose and its Benefits? Jetpack Compose is a modern UI toolkit recently launched by Google which is used for building native Android UI. It simplifies and accelerates the UI development with less code, Kotlin APIs, and powerful tools.  Declarative Compatible Increase development speed Concise and Idiomatic Kotlin Easy to maintain Written in Kotlin To read more, refer  to  the article:  Jetpack Compose in Android Aaaaaa
Read more

Kotlin Some important unsorted interview questions and answers

Image
  What is inline class in Kotlin and when do we need one? Provide an example.  What is inline class in Kotlin and when do we need one? Provide an example. Senior Answer Sometimes it is necessary for business logic to create a wrapper around some type. However, it introduces runtime overhead due to additional heap allocations. Moreover, if the wrapped type is primitive, the performance hit is terrible, because primitive types are usually heavily optimized by the runtime. Inline classes  provide us with a way to wrap a type, thus adding functionality and creating a new type by itself. As opposed to regular (non-inlined) wrappers, they will benefit from improved performance. This happens because the data is inlined into its usages, and object instantiation is skipped in the resulting compiled code. inline class Name ( val s : String ) { val length : Int get ( ) = s . length fun greet ( ) { println ( "Hello, $s " ) } } fun ma...
Read more

Null safety based Kotlin interview questions and answers

Image
Nullable Non Nullable Types What’s Null Safety and Nullable Types in Kotlin? What is the Elvis Operator? Kotlin puts a lot of weight behind null safety which is an approach to prevent the dreaded Null Pointer Exceptions by using nullable types which are like  String? ,  Int? ,  Float?  etc. These act as a wrapper type and can hold null values. A nullable value cannot be added to another nullable or basic type of value. To retrieve the basic types we need to use safe calls that unwrap the Nullable Types. If on unwrapping, the value is null we can choose to ignore or use a default value instead. The Elvis Operator is used to safely unwrap the value from the Nullable. It’s represented as  ?:  over the nullable type. The value on the right hand side would be used if the nullable type holds a null. var str: String ? = "JournalDev.com" var newStr = str?: "Default Value" str = null newStr = str?: "Default Value" How is  !! different from ?. in unwrappi...
Read more