choosing-what-to-test

Categorize Android code state to select unit, instrumented, or UI test targets.

303|10|Updated May 15, 2026
One-click install
npx skills add https://github.com/skydoves/android-testing-skills --skill choosing-what-to-test
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: choosing-what-to-test
Source: https://github.com/skydoves/android-testing-skills/tree/main/fundamentals/concepts/choosing-what-to-test
Command: npx skills add https://github.com/skydoves/android-testing-skills --skill choosing-what-to-test

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It helps you decide what to test in an Android codebase so your suite covers high-value state changes and avoids low-value framework and library verification.

Core Features & Use Cases

  • State coverage mapping: Guides decisions across UI-observable state, ViewModel/in-memory state, persisted state (DB/DataStore/files), other system state, and error/edge cases.
  • Explicit avoid-list guardrails: Prevents prioritizing unit tests for framework entry points like Activities, Fragments, and Services, and avoids testing third-party or framework internals.
  • Edge-case mining checklist: Ensures you review boundary conditions, malformed inputs, storage/network failures, concurrency, process death/restoration, and configuration changes.
  • Decision matrix: Recommends test types and locations (small unit vs small/medium instrumented vs big UI) based on what the code touches.

Quick Start

Use the choosing-what-to-test skill to get a tailored testing plan for the specific module you are reviewing, including what state categories to cover, what to avoid, and which edge cases to include.

Frequently Asked Questions about choosing-what-to-test

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

FAQPage Schema
How do I decide what to test in an Android module to ensure high-value state coverage?

Android testing strategy should avoid writing unit tests for framework entry points like Activities, Fragments, and Services, and skip verifying third-party library internals to keep the test suite focused on high-value state changes.

How do I write tests for Android ViewModel and repository state changes?

Android edge-case testing should include boundary conditions, malformed inputs, network failures, concurrency issues, process death restoration, and configuration changes to ensure robust state coverage across UI and instrumented tests.

What's the best way to choose between unit, instrumented, and UI tests for Android features?

Android test coverage requires covering screen state, in-memory state, persisted state, other system state, and error edge cases, using a decision matrix to map these categories to small unit, medium instrumented, or big UI tests.

What Android components should I avoid testing to prevent low-value framework verification?

Android testing guardrails recommend avoiding unit tests for framework entry points like Activities, Fragments, and Services, and skipping tests for third-party or framework internals to maintain high-value state coverage.