testing-setup

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha ba2d4bc1b905 · 31 Oct 2026Report an issue or request a re-scan

• Publisherandroid GitHub organizationOwner of the repository this skill is read from
• Source folderandroid/skills/testing/testing-setupThe exact folder we audited
• LicenceApache-2.0As the repository states it
• Commit pinned for this verdictba2d4bc1b905A new audit runs when the source changes
• Repository statusNot archivedLast push 2 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Analyze and create a testing strategy for Android apps - install testing

---
name: testing-setup
description: 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.
license: Complete terms in LICENSE.txt
metadata:
  author: Google LLC
  last-updated: '2026-10-28'
  keywords:
  - android
  - testing
  - ui tests
  - screenshot tests
  - coverage
---

## 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](references/android/training/dependency-injection/hilt-testing.md), [Koin Instrumented tests](https://insert-koin.io/docs/reference/koin-android/instrumented-testing)).

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](references/android/studio/preview/compose-screenshot-testing-with-testsuites.md).
  - **Lower AGP versions:** use the [legacy standalone plugin setup](references/android/studio/preview/compose-screenshot-testing.md) 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](references/android/studio/preview/compose-screenshot-testing-with-testsuites.md).
- 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)
- **Im

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/android/skills
git -C skills checkout ba2d4bc1b905

Works in

1. 2026-10-31
   ✓SAFE B 89 / 100

   first audit · source ba2d4bc1b905

Questions about testing-setup

• github.com/android/skills/tree/main/testing/testing-setup — the audited source at commit ba2d4bc1b905 and every finding aboveObserved · 31 Oct 2026

Spotted something wrong? Report a correction · Methodology