Menu
Analyze and create a testing strategy for native Android apps - install testing libraries, set up test infrastructure, create harnesses for unit tests, UI tests, screenshot tests, and end-to-end tests.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Analyzes Android build files and R8 keep rules to identify redundancies, broad package-wide rules, and rules that subsume library consumer keep rules. Use when developers want to optimize their app's size, remove redundant or overly broad keep rules, or troubleshoot Proguard configurations.
Helps developers integrate, debug, and resolve Play Engage SDK implementation issues. Use when adding Engage SDK support, generating publishing code, mapping data classes to entities, or fixing SDK-related errors.
Use this skill when upgrading or migrating an Android project from any legacy Google Play Billing Library (PBL) version to the latest stable version of PBL.
Instructions to make or update an app's UI so that it adapts to different Android devices including phones, tablets, foldables, laptops, desktop, TV, Auto and XR. It includes how to handle different window sizes, pointing devices (such as mouse) and text entry devices (such as keyboard) using the Compose MediaQuery API. It also covers multi-pane layouts using Navigation3 Scenes, adaptive UI components (such as buttons) with varying target sizes, and adaptive layouts (including navigation areas - nav rails and nav bars) using the Compose Grid and FlexBox APIs.
Provides a structured workflow for migrating an Android XML View to Jetpack Compose. This skill details the step-by-step process, from planning and dependency setup, to theming and layout migration, validation and XML cleanup. Use this skill when you need to migrate an XML View to Jetpack Compose in an Android project. It solves the problem of converting the UI of a legacy XML View into modern, declarative Compose components while maintaining interoperability.
Use this skill to integrate the Jetpack Compose Styles API into an Android project. This skill guides you through upgrading dependencies, setting up component themes, making custom components styleable, and migrating existing layout properties to use unified styles. Migrate custom design system components, replace hard coded parameters with Style attributes, and use Modifier.styleable for interaction states.
| name | testing-setup |
| description | Analyze and create a testing strategy for native Android apps - install testing libraries, set up test infrastructure, create harnesses for unit tests, UI tests, screenshot tests, and end-to-end tests. |
| license | Complete terms in LICENSE.txt |
| metadata | {"author":"Google LLC","last-updated":"2026-06-02","keywords":["android","testing","ui tests","screenshot tests","coverage"]} |
To understand the testing setup of an existing project, look for these dependencies in the libs.versions.toml file, or build files:
androidx.compose.ui:ui-test-*)androidx.test.espresso:espresso-core, androidx.test:runner, androidx.test:rules.If there is no Dependency Injection framework, install one: if it's a multiplatform application, ask the user whether they want to install Koin, or kotlin-inject. If it's not multiplatform, install Hilt.
Install the testing dependencies (for example com.google.dagger:hilt-compiler
that should be applied with a kspAndroidTest configuration).
[!IMPORTANT] Important: Always consult the documentation of the applicable framework to learn about testing (for
example: Hilt testing guide, Koin Instrumented tests).
For instrumented tests, create and configure (by adding
testInstrumentationRunner to the build gradle files) a new test runner and
apply the testing rules required by the framework (for example in Hilt, annotate
your test classes with @HiltAndroidTest and apply the HiltAndroidRule).
Other frameworks use other mechanisms, consult their documentation.
Unless otherwise specified, respect the current stack of testing frameworks.
If there are no testing frameworks, and the user didn't specify any preference, install the following:
io.mockk:mockk). Do not install it unless it
is clearly necessary.If instrumented screenshot tests are requested, install Dropshots.
If end-to-end testing is requested, install UI Automator.
In the next sections you'll be asked to create tests. If you have dependencies on Android framework classes, or entities that are not part of the codebase:
First, use a fake. If it doesn't exist, create an interface for the class and a "Default" implementation with the existing code. Add the Fake version to the test sourceset (test or androidTest).
If not possible to use a fake (example: no access to the class or interface), mock the dependencies.
If you need to fake components to make testing easier and faster and more reliable, replace slow and problematic dependencies with fakes. Use runtime fakes using the Dependency Injection framework installed to:
Create a task to add or review unit tests in every file that contains business logic (ViewModels, Repositories, database-related classes such as DAOs, etc.). Don't create unit tests for Activities, Compose layouts, or dependency injection configuration files.
Espresso or Compose UI tests live in the test sourceset because they will be
run with Robolectric. If instrumented (emulator or device) tests are requested,
put them in the androidTest sourceset.
If the database is using SQLite (using Room, SQLDelight, etc.), create instrumented tests using an in-memory database to make sure that they work with the SQLite engine on device.
Irrespective of the framework used, screenshot tests focus on 2 types of tests:
Behavior isn't tested with screenshots, but do test different common scenarios if their UIs change a lot depending on the state. For example, test loading screens by injecting a loading state to the UI or simulating it with a fake.
Test the UI logic using behavior tests, which ensures that the UIs react as expected when different states are passed, and when user actions are performed.
ComponentActivity to access resources such as strings.testTag.Use Espresso to match views and interact with them.
Create a test suite to verify navigation logic. Include:
For Compose layouts, use DeviceConfigurationOverride described in "UI testing
common patterns" to simulate
different window sizes, font scales
Create a low number (about 5% of all tests) of end-to-end tests that cover big user journeys. Use Compose Test APIs or Espresso for that. If you have to access platform features (notifications, system UI...), use UI Automator.
If you need to take screenshots of the app running in a device, use Dropshots. You need a device for screenshot tests when verifying interaction with the system UI (examples: edge-to-edge rendering, notifications, picture-in-picture)
Install the com.dropbox.dropshots plugin in the module and a Dropshots()
JUnit Rule. Create a new instrumented screenshot test for one of the app's
features.
Install jacoco for local testing code coverage.
jacoco plugin to each module that contains tests.Ask whether to document the findings of the analysis and the changes applied to the testing strategy. If the user agrees:
If there is an AGENTS.md file present in the project, update it with any changes you've made to the testing strategy.
If there is no AGENTS.md file, create a new file (docs/testing.md) with a description of the testing strategy, including the commands needed to run every type of test, where the screenshot reference files live, etc. Also create a new AGENTS.md file in the root and create a link to docs/testing.md.