AutoGineer
Generated banner for Testing Setup
Generated logo for Testing Setup

Testing Setup

Android (Google)OfficialCreated by Google LLCDistributed by Android (Google)

  • Skill
  • Workflow
  • Software development
  • Apache-2.0
  • No issues found
Download ZIP

From the author

Analyze and create a testing strategy for Android apps - install testing libraries, set up test infrastructure, create harnesses for unit tests, UI tests, screenshot tests, and end-to-end tests.
— the description by Google LLC

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured, step-by-step procedure for establishing a complete testing infrastructure in Android projects. It guides developers through analyzing existing dependencies, configuring dependency injection for testability, and implementing various testing layers including unit, UI, screenshot, and end-to-end tests. It emphasizes modern practices like Compose-based screenshot testing and provides clear paths for both legacy and current Android Gradle Plugin configurations.

What it does

  • Analyzes current project dependencies and testing frameworks.
  • Configures dependency injection frameworks for testable code.
  • Sets up unit, UI, and end-to-end testing harnesses.
  • Implements screenshot testing using Compose or device-based tools.
  • Provides guidance on refactoring code for better testability.
  • Documents the testing strategy and setup for the project.

When to use it

  • When starting a new Android project and needing a testing foundation.
  • When an existing project lacks a formal or comprehensive testing strategy.
  • When migrating or upgrading screenshot testing configurations.
  • When needing to improve test coverage for business logic or UI components.

Advantages

  • Standardizes testing practices across Android modules.
  • Supports both modern Compose and legacy View-based architectures.
  • Provides clear migration paths for screenshot testing.
  • Promotes testable code through dependency injection and fakes.

Usage examples

“Analyze my current Android project and suggest a testing strategy.”
The agent will examine your build files, identify existing testing dependencies, and generate a report outlining the recommended setup for unit, UI, and screenshot tests.
“Set up screenshot testing for my Compose-based Android app.”
The agent will configure the necessary screenshot engine, update your build files, and guide you through creating your first screenshot test suite.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/android/testing-setup/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip testing-setup.zip -d .agents/skills

Documentation by Google LLC

Step 1: Analyze the current testing setup

To understand the testing setup of an existing project, look for these dependencies in the libs.versions.toml file, or build files:

  1. Dependency Injection framework used. For example, Hilt, Koin, Anvil, or vanilla Dagger.

  2. Unit (local) testing framework this project uses. For example, JUnit4 or JUnit5.

  3. Mocking framework (if any) used for unit tests, and for instrumented and UI tests. For example, Mockito or Mockk.

  4. Robolectric. Identify which of these three uses apply:

    1. Used in unit tests to have fakes for platform entities

    2. To run behavior UI tests without a device or emulator. For example, used to run Espresso or Compose tests.

    3. To do screenshot testing with Roborazzi

  5. Is the app 100% Compose, Views or hybrid?

  6. Behavior UI tests:

    1. Compose Tests (androidx.compose.ui:ui-test-*)

    2. Espresso Tests for Views. Check for wrappers such as Kaspresso. Dependencies: androidx.test.espresso:espresso-core, androidx.test:runner, androidx.test:rules.

  7. Screenshot tests. Identify which of these types the project uses:

    1. Instrumented (device-based). For example, using Dropshots.

    2. Based on Robolectric, so they run locally. For example, using Roborazzi.

    3. Based on LayoutLib, so they run locally. For example, Paparazzi, or the Compose Preview Screenshot Testing tool.

  8. End to end tests (also known as Release Candidate tests) always run on device and use high-level frameworks such as UIAutomator, Appium, or Robotium.

  9. Generate a Markdown report with the analysis

Step 2: Set up Dependency Injection frameworks for testing

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.

Step 3: Install frameworks

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:

  • JUnit4 for local and instrumented tests

  • JaCoCo for test coverage

  • For UI tests: if the project has views, Espresso. If it's fully Compose, use the Compose Testing APIs.

  • Robolectric to run UI Tests

  • Compose Preview Screenshot Testing tool for screenshot tests. Check the project's AGP version first, then pick the matching setup and follow it strictly:

    • AGP 9.5.0-alpha03 or higher (recommended): configure an AGP test suite using testOptions { screenshotTests.create(...) }, as described in Screenshot testing with test suites.

    • Lower AGP versions: use the legacy standalone plugin setup with com.android.compose.screenshot, and tell the user it's deprecated. Don't upgrade AGP as part of setting up screenshot tests. Mention that test suites are available on 9.5.0-alpha03 or higher, and leave the upgrade as a separate decision.

    Don't combine both setups in the same module. If the project already uses the standalone plugin and its AGP version supports test suites, offer to migrate it using the tasks and paths mapping table in Screenshot testing with test suites.

  • Dropshots for device screenshot tests

  • If a mocking framework is necessary, install Mockk (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.

Step 4: Refactor and create fakes for testing

Refactor for unit tests

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.

Refactor for UI tests

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:

  • Simulate different scenarios with the user (wrong credentials or a password reset flow), with a server (no connection, server down, or bad JSON from the server) or with a platform component (insufficient permissions, no disk space, no front camera available)

  • Improve speed and reliability (replacing a database with an in-memory database, replacing a repository with an in-memory fake to avoid hitting the network)

Step 5: Unit testing

Create a task to add or review unit tests in every file that contains business logic (ViewModels, Repositories, and database-related classes such as DAOs). Don't create unit tests for Activities, Compose layouts, or dependency injection configuration files.

Step 6: UI testing

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.

Step 7: Test databases

If the database is using SQLite (through a library such as Room or SQLDelight), create instrumented tests using an in-memory database to make sure that they work with the SQLite engine on device.

Step 8: Screenshot tests

Regardless of the framework used, screenshot tests focus on two types of tests:

  • Screen-level screenshot tests, where each screen is tested in nine different sizes, combining compact, medium and expanded widths (400, 610, 900 dp) and heights (400, 500 and 1000 dp).

  • Screen-level variations. Add a mobile (400x500) screenshot of:

    • All the alternative themes, if used.

    • Font scale set to 1.5.

  • Component-level screenshot tests, where each component is tested in different themes and font scales.

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.

Step 9: UI Behavior tests

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.

Compose UI behavior tests

  • Use the ComposeTestRule with a ComponentActivity to access resources such as strings.

  • Always match with semantic matchers first. If the matcher is too complicated to write (using more than three matchers to find a single element), use testTag.

  • Always verify state restoration.

Views (XML) UI behavior tests

Use Espresso to match views and interact with them.

Step 10: Navigation tests

Create a test suite to verify navigation logic. Include:

  • Back handling

  • Deeplinks

  • Special patterns like "exit through home" with multiple backstacks.

Step 11: Simulate different window sizes and settings

For Compose layouts, use DeviceConfigurationOverride described in "UI testing common patterns" to simulate different window sizes, font scales

Step 12: End-to-end tests

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 such as notifications or 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)

Step 13: Instrumented Screenshot tests

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.

Step 14: Install JaCoCo

Install JaCoCo for local testing code coverage.

  • Add the jacoco plugin to each module that contains tests.

Final touches

  • 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 and where the screenshot reference files live. Also create a new AGENTS.md file in the root and create a link to docs/testing.md.

Files

references/android/develop/ui/compose/testing/common-patterns.md

Video

You can test your Compose app with well-established approaches and patterns.

Test in isolation

ComposeTestRule lets you start an activity displaying any composable: your full application, a single screen, or a small element. It's also a good practice to check that your composables are correctly encapsulated and they work independently, allowing for easier and more focused UI testing.

This doesn't mean you should only create unit UI tests. UI tests scoping larger parts of your UI are also very important.

Access the activity and resources after setting your own content

Oftentimes you need to set the content under test using composeTestRule.setContent and you also need to access activity resources, for example to assert that a displayed text matches a string resource. However, you can't call setContent on a rule created with createAndroidComposeRule() if the activity already calls it.

A common pattern to achieve this is to create an AndroidComposeTestRule using an empty activity such as ComponentActivity.

class MyComposeTest {

    @get:Rule
    val composeTestRule = createAndroidComposeRule<ComponentActivity>()

    @Test
    fun myTest() {
        // Start the app
        composeTestRule.setContent {
            MyAppTheme {
                MainScreen(uiState = exampleUiState, /*...*/)
            }
        }
        val continueLabel = composeTestRule.activity.getString(R.string.next)
        composeTestRule.onNodeWithText(continueLabel).performClick()
    }
}

Note that ComponentActivity needs to be added to your app's AndroidManifest.xml file. Enable that by adding this dependency to your module:

debugImplementation("androidx.compose.ui:ui-test-manifest:$compose_version")

Custom semantics properties

You can create custom semantics properties to expose information to tests. To do this, define a new SemanticsPropertyKey and make it available using the SemanticsPropertyReceiver.

// Creates a semantics property of type Long.
val PickedDateKey = SemanticsPropertyKey<Long>("PickedDate")
var SemanticsPropertyReceiver.pickedDate by PickedDateKey

Now use that property in the semantics modifier:

val datePickerValue by remember { mutableStateOf(0L) }
MyCustomDatePicker(
    modifier = Modifier.semantics { pickedDate = datePickerValue }
)

From tests, use SemanticsMatcher.expectValue to assert the value of the property:

composeTestRule
    .onNode(SemanticsMatcher.expectValue(PickedDateKey, 1445378400)) // 2015-10-21
    .assertExists()

[!WARNING] Warning: You should only use custom Semantics properties when it's hard to match a specific item using the given finders and matchers. Using custom Semantics properties to expose visual properties such as colors, font size or rounded corner radius is not recommended, as it can pollute production code and wrong implementations can lead to bugs that are hard to find.

Verify state restoration

Verify that the state of your Compose elements is correctly restored when the activity or process is recreated. Perform such checks without relying on activity recreation with the StateRestorationTester class.

This class lets you simulate the recreation of a composable. It's especially useful to verify the implementation of rememberSaveable.

class MyStateRestorationTests {

    @get:Rule
    val composeTestRule = createComposeRule()

    @Test
    fun onRecreation_stateIsRestored() {
        val restorationTester = StateRestorationTester(composeTestRule)

        restorationTester.setContent { MainScreen() }

        // TODO: Run actions that modify the state

        // Trigger a recreation
        restorationTester.emulateSavedInstanceStateRestore()

        // TODO: Verify that state has been correctly restored.
    }
}

Test different device configurations

Android apps need to adapt to many changing conditions: window sizes, locales, font sizes, dark and light themes, and more. Most of these conditions are derived from device-level values controlled by the user and exposed with the current Configuration instance. Testing different configurations directly in a test is difficult since the test must configure device-level properties.

DeviceConfigurationOverride is a test-only API that lets you simulate different device configurations in a localized way for the @Composable content under test.

The companion object of DeviceConfigurationOverride has the following extension functions, which override device-level configuration properties:

To apply a specific override, wrap the content under test in a call to the DeviceConfigurationOverride() top-level function, passing the override to apply as a parameter.

For example, the following code applies the DeviceConfigurationOverride.ForcedSize() override to change the density locally, forcing the MyScreen composable to be rendered in a large landscape window, even if the device the test is running on doesn't support that window size directly:

composeTestRule.setContent {
    DeviceConfigurationOverride(
        DeviceConfigurationOverride.ForcedSize(DpSize(1280.dp, 800.dp))
    ) {
        MyScreen() // Will be rendered in the space for 1280dp by 800dp without clipping.
    }
}

<br />

To apply multiple overrides together, use DeviceConfigurationOverride.then():

composeTestRule.setContent {
    DeviceConfigurationOverride(
        DeviceConfigurationOverride.FontScale(1.5f) then
            DeviceConfigurationOverride.FontWeightAdjustment(200)
    ) {
        Text(text = "text with increased scale and weight")
    }
}

<br />

Custom failure handling in tests

Debugging UI tests often requires inspecting the screen state and composition hierarchy when an assertion fails.

Compose provides a native failure handling pipeline to streamline diagnostics. You can automatically capture screenshots and UI hierarchies upon failure, or register custom handlers to forward crash telemetry to external tools.

[!NOTE] Note: The APIs associated with the failure handler pipeline (TestFailurePolicy, TestFailureHandler, and FailureContext) are included in androidx.compose.ui:ui-test:1.13.0-alpha01+ and androidx.compose.ui:ui-test-junit4:1.13.0-alpha01+.

Configure failure handling

To configure failure handling, pass a TestFailurePolicy object to ComposeUiTestConfig.

Capture built-in failure artifacts

To capture screenshots and UI hierarchies upon test failure, set the screenshotCaptureMode and uiHierarchyCaptureMode properties in TestFailurePolicy.

class MyComposeTest {
    private val customConfig = ComposeUiTestConfig(
        failurePolicy = TestFailurePolicy(
            screenshotCaptureMode = TestFailurePolicy.CaptureMode.Enabled,
            uiHierarchyCaptureMode = TestFailurePolicy.CaptureMode.Enabled
        )
    )

    @Test
    fun myFirstTest() = runComposeUiTest(config = customConfig) {
        // ...
    }
}

<br />

Use a custom failure handler

To define custom behavior for test failures, add a TestFailureHandler to the failureHandlers list. Each handler receives a FailureContext object that contains the original error and a list of artifacts generated by the preceding pipeline handlers.

class MyComposeTestWithHandler {
    private val customConfig = ComposeUiTestConfig(
        failurePolicy = TestFailurePolicy(
            screenshotCaptureMode = TestFailurePolicy.CaptureMode.Enabled,
            failureHandlers = listOf(
                TestFailureHandler { context ->
                    val screenshot = context.artifacts.firstOrNull {
                        it.type == FailureArtifact.Type.Screenshot
                    }
                    // ...
                }
            )
        )
    )

    @get:Rule
    val rule = createComposeRule(config = customConfig)

    // ...
}

<br />

Configure captures for an entire test suite

You can enable failure artifact captures for an entire test suite by passing instrumentation runner arguments in your module's build.gradle file. This eliminates the need to update individual test files.

// build.gradle.kts
android {
    defaultConfig {
        // ...
        testInstrumentationRunnerArguments["androidx.compose.ui.test.failure.isUiHierarchyCaptureEnabled"] = "true"
        testInstrumentationRunnerArguments["androidx.compose.ui.test.failure.isScreenshotCaptureEnabled"] = "true"
    }
}
Configuration precedence

The framework evaluates both the local TestFailurePolicy and the suite-level runner arguments:

  • If you explicitly set a mode to CaptureMode.Enabled/Disabled in your test failurePolicy, this overrides the runner argument.

  • If you set a mode to CaptureMode.Unspecified (or leave failurePolicy as null), the framework falls back to the runner argument.

Additional Resources

  • Test apps on Android: The main Android testing landing page provides a broader view of testing fundamentals and techniques.

  • Fundamentals of testing: Learn more about the core concepts behind testing an Android app.

  • Local tests: You can run some tests locally, on your own workstation.

  • Instrumented tests: It is good practice to also run instrumented tests. That is, tests that run directly on-device.

  • Continuous integration: Continuous integration lets you integrate your tests into your deployment pipeline.

  • Test different screen sizes: With some many devices available to users, you should test for different screen sizes.

  • Espresso: While intended for View-based UIs, Espresso knowledge can still be helpful for some aspects of Compose testing.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Google LLC
Publisher
Android (Google) (Official)
Distributed by
Android (Google)
Source
android/skills · testing/testing-setup · commit bf68e2d
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE.txt)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Google LLC or Android (Google).

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download testing-setup.zip