Android testing 101: Types, tools, and examples

What is testing on an Android?

Android testing is the process of evaluating and verifying the functionality, performance, and quality of Android applications.

Testing is a critical part of the software development cycle that uses specialized techniques and tools to identify and fix defects, ultimately ensuring that an app is ready for end users.

Android testing also carries a challenge other platforms don’t: fragmentation. One app may run across hundreds of device models, OS versions, screen sizes, and manufacturer skins that each alter behavior slightly. A layout that looks perfect on a Pixel emulator can clip its buttons on a foldable.

How many types of testing are done on Androids?

There are various types of testing in Android, each targeting different aspects of an application’s functionality and performance. Let’s delve into some of these testing types and their use cases.

1. Unit testing

Unit testing entails examining individual units or components of an application in isolation. Developers create unit tests to verify the functionality of small code segments, guaranteeing the production of anticipated outcomes. Unit tests facilitate the early detection of bugs and help maintain code quality.

Imagine you’re developing a fitness-tracking app with a step-counter feature. You can write a unit test to verify that the step-counting algorithm accurately increments the step count when new steps are detected.

Most Android unit tests use JUnit, live in the `src/test/` source set, and run on your machine’s JVM in milliseconds. Dependencies are swapped for fakes with tools like MockK or Mockito, and Robolectric can simulate framework classes like `Context` without a device.

2. Integration testing

Integration testing focuses on verifying the interactions between different components within an application. It ensures that these components work well together and exchange data correctly.

For example, on an e-commerce website, integration testing would involve confirming that the shopping cart module and the payment gateway module interact seamlessly, ensuring that items are correctly transferred for payment processing.

In an Android codebase, these tests often cover the seam between a repository and its data sources: a `ViewModel` requests data, the repository caches it in Room, and the right state reaches the UI. Because Room uses the device’s SQLite engine, they usually run instrumented.

3. Functional testing

Functional testing involves assessing whether the application’s features and operations function according to their intended purpose. It checks that the app does what the requirements say it should, from the user’s point of view rather than the code’s.

When performing functional testing, developers devise test scenarios to simulate genuine user engagements, affirming that the application operates as anticipated.

For example, functional testing for a messaging app would involve simulating sending a message to confirm it appears in the thread, the delivery receipt updates, and the recipient’s notification fires.

User interface testing involves checking the graphical user interface (GUI) of the app.

4. UI testing

User interface testing involves checking the graphical user interface (GUI) of the app. It verifies that UI elements display correctly, respond to user interactions, and follow design guidelines.

For example, a tester who needed to verify that images load correctly in a gallery app when the user swipes through different images would conduct UI testing.

Espresso remains the standard for View-based screens, Compose apps use the Compose test APIs, and UI Automator handles anything crossing app boundaries, such as permission dialogs.

Screenshot testing is also common: tools like Paparazzi compare a rendered component against an approved baseline image and fail the build when it changes.

5. Performance testing

Performance testing evaluates an app’s responsiveness, stability, and resource consumption under various user loads. This type of testing helps ensure that the app remains functional and performs well even during peak usage and helps identify where the app’s performance can be improved and optimized.

In a navigation app, performance testing might involve assessing how quickly the app calculates and displays routes, especially in areas with poor network connectivity.

The Jetpack Macrobenchmark library measures user-visible metrics such as cold startup and frame timing, and Baseline Profiles complement it by pre-compiling critical code paths.

Always benchmark release builds on real hardware; debug builds are too slow to draw

6. Security testing

Security testing aims to identify vulnerabilities and weaknesses that could potentially compromise the app’s security and user data. It is crucial to safeguard sensitive user information and ensure the app’s integrity.

For example, a tester conducting security testing on a banking app would assess the app for potential vulnerabilities such as data leaks, unauthorized access, or inadequate encryption measures.

Typical checks include confirming credentials are stored in encrypted storage and that exported components leak nothing to other apps.

7. Usability testing

Usability testing evaluates the user-friendliness of an app. It focuses on ensuring that users can easily navigate the app, perform actions intuitively, and have a positive overall experience.

Usability testing is often conducted by real users interacting with the app, but it can also be done by developers or testers. Accessibility belongs here too: TalkBack, touch target sizes, and a 1.5x font scale surface problems no assertion catches.

Suppose you’re designing a travel booking app. To perform usability testing, you would ask users to book a flight and a hotel, observing how they interact with the interface and noting any difficulties they encounter.

8. Automated testing

Automated testing in Android involves using scripts and tools to automatically run tests on the app’s functionality. This type of testing is efficient for repeated and complex tests, saving time and reducing human errors.

Automation is a delivery method rather than a test type: every layer above can be wired into a continuous integration pipeline that verifies each pull request.

An end-to-end test for a food delivery app would sign in, add items to the cart, check out against a staging backend, and assert the confirmation total.

9. End-to-end testing

End-to-end testing involves evaluating the entire flow of an application, including multiple components, subsystems, and interactions, to ensure that they work harmoniously. It helps identify any issues that arise when different parts of the app are connected.

An end-to-end test for a food delivery app would sign in, add items to the cart, check out against a staging backend, and assert the confirmation total.

Android testing types at a glance

Android testing tools and frameworks

Most teams assemble a small stack rather than one tool for everything.

How to conduct Android testing

Conducting effective Android testing requires several key steps to ensure the quality and reliability of your application. By following a structured approach, you can identify issues early in the development process and deliver a seamless user experience.

1. Understand local vs. instrumented tests

Every Android test falls into one of two buckets, and choosing the wrong one is the top cause of slow, flaky suites.

Local tests run on your development machine’s JVM, while instrumented tests run on a real or emulated Android device.

Local tests live in `src/test/java` and suit business logic. Instrumented tests live in `src/androidTest/java`, get a genuine `Context` and full framework access, and are right for UI behavior and device state. Run them with `./gradlew test` and `./gradlew connectedAndroidTest`.

The trade-off is fidelity versus speed. Google’s documentation recommends instrumented tests “only in cases where you must test against the behavior of a real device,” and suggests a rough split of 70% small tests, 20% medium, and 10% large.

Before you begin testing, you need to set up the necessary tools and frameworks to facilitate the testing process.

2. Set up testing environment

Before you begin testing, you need to set up the necessary tools and frameworks to facilitate the testing process.

Here are the key things to consider:

1. Testing frameworks: Depending on the type of testing you’re conducting, choose appropriate testing frameworks such as JUnit, Espresso, the Compose test APIs, or UI Automator.
2. Dependencies: Add unit test libraries with `testImplementation` and instrumented ones with `androidTestImplementation`, then set `AndroidJUnitRunner` as the test runner.
3. Android Studio: Ensure you have the latest version of Android Studio It provides tools for testing, debugging, and profiling your app.
4. Emulators and devices: Set up emulators with different Android versions and screen sizes, and consider using physical devices for real-world testing scenarios.

3. Write test cases

Writing comprehensive test cases is essential to cover different aspects of your application’s functionality. Each test case should focus on a specific scenario or use case.

Here’s how you can write test cases:

• Identify scenarios: Determine the key scenarios that need testing, including user flows, edge cases, error handling, and performance benchmarks.
• Create test classes: Organize your tests into separate classes for better maintainability. For instance, create separate classes for unit tests, UI tests, integration tests, etc.
• Structure each test: Follow a given-when-then arrangement, and name tests descriptively, so `emailValidator_invalidDomain_returnsFalse` reads like a bug title when it fails.
• Write assertions: Within each test case, include assertions to validate the expected outcomes. Assertions compare actual results with expected values or conditions.

4. Choose the right devices

Emulators and physical devices answer different questions, and a mature strategy uses both plus a cloud farm for breadth.

A practical split: emulators on every pull request, two or three physical devices nightly, and a cloud farm such as Firebase Test Lab before each release.

5. Execute tests

After creating test cases, it’s time to run them on different devices and emulators to ensure compatibility and reliability.

To execute tests effectively, here are the options to consider:

1. Select test configuration: Choose the appropriate test configuration based on the type of testing you’re performing (unit, UI, integration, etc.).
2. Run locally first: JVM tests finish in seconds and should pass before anything touches a device.
3. Run on emulators: Gradle Managed Devices let you declare emulators in your build file so the build creates and tears them down automatically.
4. Use physical devices: Test on physical devices to simulate real-world conditions and identify device-specific issues.
5. Parallel testing: If feasible, run tests in parallel to save time and speed up the testing process.

After creating test cases, it’s time to run them on different devices and emulators to ensure compatibility and reliability.

6. Analyze results

Once tests are executed, you need to analyze the results to identify any failures, performance bottlenecks, or defects.

Most testing frameworks generate detailed test reports that show which tests passed, which failed, and any exceptions encountered; Gradle writes HTML reports to `build/reports/`.

You should also investigate the cause of test failures by examining error messages, stack traces, and logcat outputs; debugging tools in Android Studio can help pinpoint the issue. For performance testing, tools like Android Profiler can help analyze metrics such as CPU usage, memory consumption, and network activity.

7. Make tests repeatable

A test that passes locally and fails in CI is worse than no test, because the team stops trusting the suite.

1. Isolate state: Reset databases, caches, and preferences before each test instead of relying on execution order.
2. Control the clock and the network: Inject fake time sources and stub HTTP responses with MockWebServer.
3. Never sleep: Replace `Thread.sleep()` with Espresso idling resources or Compose synchronization.
4. Fix flakes immediately, since auto-retrying failures hides real bugs.
5. Run the same command locally that CI runs.

8. Iterate and improve

Testing is an iterative process. As you identify issues and make improvements, the testing process should be repeated to validate fixes and enhancements, address bugs found during testing, and ensure that the test cases that previously failed now pass.

Also, remember that the testing phase never really ends, as new updates keep coming from user reviews and added functionality, so tests should run again as new code lands. A useful habit is writing a failing test for every production bug before fixing it.

Android testing best practices

Here are some of the most important best practices to follow in Android testing.

1. Keep the pyramid shape: many fast unit tests, fewer integration tests, and a few end-to-end tests over revenue-critical flows.
2. Test behavior, not implementation, so refactors don’t break passing tests.
3. Use stable test tags rather than display text, which changes with copy edits and localizations.
4. Gate merges on tests: a suite that isn’t required to pass is documentation, not a safety net.
5. Keep the suite fast: if feedback takes more than ten minutes, developers will bypass it.
6. Measure coverage but don’t chase it: This shows untested areas, not correctness.

Android testing use case

These principles scale beyond a single app. One Tricentis customer shows what happens when mobile-first organizations apply them across a large application estate.

Problem

T-Mobile’s team supports 52 applications across retail, digital, care, and prepaid for over 110 million customers. Principal Architect Raju Chavan found virtually no test automation in place when he arrived, and manual test data requests and reporting consumed hours of every cycle.

Solution

The team adopted Tricentis Tosca for its low-code, model-based approach, letting manual testers build and reuse test cases without a coding background. They modeled 300+ customer business processes and used risk-based testing to keep scope on high-value areas.

Outcome

Automation went from 0 to 60% within 8 to 10 months, and 300+ team members became skilled Tosca users in the first year. Test data request time fell 50%, defect reporting dropped from ten minutes to near-instant, and one billing validation cycle shrank from two weeks to three days.

Read more about this case study here.

If you’re starting from scratch, pick the user journey that matters most to your business and cover it end to end.

Conclusion

Android testing is an indispensable aspect of app development, ensuring your application functions seamlessly across various devices and situations.

The key takeaways are straightforward. Know whether each test belongs on the JVM or on a device, and default to the fastest option unless real-device behavior is required.

Keep most coverage in quick unit tests, and save UI and end-to-end tests for flows that would cost you money if they broke.

Use emulators for speed, physical devices for fidelity, and a cloud farm for factors you can’t buy. Treat flakiness as a defect, because a suite nobody trusts protects nothing.

If you’re starting from scratch, pick the user journey that matters most to your business and cover it end to end. Then audit your suite this week: how long it runs, how often it fails for reasons unrelated to code, and which critical flow has no coverage.

Want to automate Android testing? Explore Tricentis Tosca for scalable mobile test automation.

This post was written by Israel Oyetunji. Israel is a frontend developer with a knack for creating engaging UI and interactive experiences. He has proven experience developing consumer-focused websites using HTML, CSS, Javascript, React JS, SASS, and relevant technologies. He loves writing about tech and creating how-to tutorials for developers.