testing-setup

Analyzes and configures testing infrastructure for native Android apps including unit, UI, and screenshot tests.

Updated May 21, 2025
One-click install
npx skills add https://github.com/albertmartorell1975/MeteoMartoCompose --skill testing-setup-albertmartorell1975
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: testing-setup
Source: https://github.com/albertmartorell1975/MeteoMartoCompose/tree/main/.agents/skills/testing-setup
Command: npx skills add https://github.com/albertmartorell1975/MeteoMartoCompose --skill testing-setup-albertmartorell1975

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Setting up a complete testing strategy for an Android project is complex: you must choose frameworks, configure dependency injection for tests, create fakes, and cover unit, UI, screenshot, and end-to-end tests. This Skill analyzes an existing Android project's testing setup and installs or completes the missing 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 (Mockk, Mockito), Robolectric, and Compose vs Views usage, then generates a Markdown report. - Framework Installation & Configuration: Installs JUnit4, Jacoco, Espresso or Compose Testing APIs, Robolectric, Compose Preview Screenshot Testing, Dropshots, and UI Automator, including Hilt test runners and rules. - Test Harness Creation: Guides creation of unit tests for ViewModels and repositories, UI behavior tests, navigation tests, database tests with in-memory Room, screenshot tests across window sizes and themes, and end-to-end tests. - Use Case: You inherit an Android app with zero tests. Run this Skill to audit the codebase, install Hilt testing and Compose screenshot testing, and scaffold unit, UI, and screenshot test suites with fakes replacing network and database dependencies. ## Quick Start Analyze the testing setup of this Android project and set up unit, UI, and screenshot testing infrastructure.

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 Compose app?▼

Start by analyzing existing dependencies in libs.versions.toml, then install JUnit4, the Compose Testing APIs, and Robolectric so UI tests run locally in the test sourceset. Add Hilt testing with a custom test runner if the project uses Hilt, and Jacoco for coverage.

How do I configure Hilt for instrumented Android tests?▼

Add hilt-android-testing to androidTestImplementation with kspAndroidTest for the compiler, annotate test classes with @HiltAndroidTest, and apply HiltAndroidRule. Create a custom AndroidJUnitRunner that returns HiltTestApplication and set it as testInstrumentationRunner in the build file.

What is the difference between Roborazzi, Paparazzi, and Compose Preview Screenshot Testing?▼

Compose Preview Screenshot Testing reuses @Preview composables in a screenshotTest sourceset with Gradle tasks like validateDebugScreenshotTest. Roborazzi runs on Robolectric, Paparazzi uses LayoutLib, and Dropshots runs instrumented on a real device for system UI interactions.

Should Android UI tests go in the test or androidTest sourceset?▼

Compose or Espresso UI tests run with Robolectric belong in the test sourceset so they execute locally without a device. Instrumented tests that need an emulator or physical device, such as Dropshots screenshot tests, belong in androidTest.

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

Prefer fakes when you depend on Android framework classes or external entities: extract an interface, provide a default implementation, and place the fake in the test sourceset. Use a mocking framework like Mockk only when creating a fake is not possible.

How do I test Room databases on Android?▼

Create instrumented tests that use an in-memory Room database so queries run against the real SQLite engine on device. This validates DAO behavior, migrations, and SQL syntax that local JVM tests cannot verify.