testing-setup

Analyzes Android projects and sets up unit, UI, screenshot, and end-to-end testing infrastructure.

2|Updated Jun 21, 2026
One-click install
npx skills add https://github.com/IsKenKenYa/skills --skill testing-setup-iskenkenya
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: testing-setup
Source: https://github.com/IsKenKenYa/skills/tree/main/skills/android/testing/testing-setup
Command: npx skills add https://github.com/IsKenKenYa/skills --skill testing-setup-iskenkenya

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Setting up a coherent testing strategy for a native Android app is complex: you must choose DI frameworks, unit/UI/screenshot test stacks, configure runners, and create fakes. This Skill analyzes an existing project's testing setup and builds out the full testing infrastructure step by step. ## Core Features & Use Cases - Testing Stack Analysis: Inspects libs.versions.toml and build files to detect DI frameworks (Hilt, Koin), test runners (JUnit4/5), mocking libraries (Mockito, Mockk), Robolectric, and Compose vs Views usage, then generates a Markdown report. - Framework Installation & Configuration: Installs and configures Hilt testing, JUnit4, Jacoco coverage, Espresso or Compose UI tests, Robolectric, Compose Preview Screenshot Testing, Dropshots, and UI Automator. - Test Authoring Guidance: Creates unit tests for business logic, UI behavior tests, navigation tests, database tests with in-memory SQLite, screenshot tests across window sizes, and a small set of end-to-end tests. - Use Case: Point the Skill at an Android project with no tests; it analyzes the stack, installs Hilt testing and Compose screenshot testing, refactors dependencies behind fakes, and produces unit, UI, and screenshot tests plus a docs/testing.md strategy document. ## Quick Start Analyze this Android project's testing setup and install the recommended unit, UI, and screenshot testing frameworks.

Frequently Asked Questions about testing-setup

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I set up testing for an Android project from scratch?

Start by analyzing existing dependencies in libs.versions.toml, then install JUnit4 for local and instrumented tests, Jacoco for coverage, Espresso or Compose Testing APIs for UI tests, and Robolectric to run UI tests locally. Add Hilt testing dependencies if the project uses Hilt for dependency injection.

How do I configure Hilt for instrumented Android tests?

Add the hilt-android-testing dependency with kspAndroidTest, annotate test classes with @HiltAndroidTest, apply the HiltAndroidRule, and configure a custom AndroidJUnitRunner that uses HiltTestApplication. Create a HiltTestActivity annotated with @AndroidEntryPoint to host Compose content.

Should I use Espresso or Compose Testing for Android UI tests?

Use Compose Testing APIs if the project is fully built with Jetpack Compose, and Espresso for View-based UIs. Hybrid projects may need both. Both can run locally on Robolectric or on-device as instrumented tests in the androidTest sourceset.

What is the difference between Roborazzi, Paparazzi, and Dropshots for screenshot testing?

Roborazzi runs screenshot tests locally on Robolectric, Paparazzi uses LayoutLib for local rendering, and Dropshots runs instrumented tests on a real device. The Compose Preview Screenshot Testing tool also runs host-side tests using the screenshotTest sourceset.

When should I use fakes instead of mocks in Android tests?

Prefer fakes when you control the dependency: extract an interface, provide a Default implementation in production, and add a Fake to the test sourceset. Use mocking frameworks like Mockk only when fakes are impossible, such as when you cannot access the class or interface.

How many end-to-end tests should an Android app have?

Keep end-to-end tests to roughly 5 percent of the total test suite, covering only major user journeys. Use Compose Test APIs or Espresso for app-level flows, and UI Automator when tests must interact with platform features like notifications or system UI.