New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Choosing What To Test

by skydoves in skydoves/android-testing-skills

A skill your agent uses to pick which behaviors to cover in an Android test suite using Google's five-category state vocabulary plus the explicit "what NOT to test" list from…

Apache-2.0Auto-check passedTesting & QA

Install Choosing What To Test

skills CLI
$ npx skills add skydoves/android-testing-skills --skill choosing-what-to-test -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install skydoves/android-testing-skills choosing-what-to-test --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/skydoves/android-testing-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/fundamentals/concepts/choosing-what-to-test .claude/skills/choosing-what-to-test && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
choosing-what-to-test
GitHub stars
334
Token cost
~4.6k tokens
SKILL.md length
1,526 words
Files
1
Skills in repo
50
Repo updated
First seen
Licence
Apache-2.0

At a glance

A skill your agent uses to pick which behaviors to cover in an Android test suite using Google's five-category state vocabulary plus the explicit "what NOT to test" list from…

  • Works in 5 steps: State on screen — what the user observes… → State held in memory — ViewModel and… → Persisted state — DB, DataStore,… → …
  • The user asks what should I write tests for
  • SKILL.md covers When to use this skill, When NOT to use this skill, Prerequisites and Five categories of state to…, plus 7 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Choosing What To Test is an agent skill from skydoves/android-testing-skills. Use this skill to pick which behaviors to cover in an Android test suite using Google's five-category state vocabulary plus the explicit "what NOT to test" list from /training/testing/fundamentals/what-to-test. Covers state on screen, state held in memory (ViewModels), persisted state (DB / DataStore / files), other state (system bars / system services), and errors / edge cases. Includes Google's verbatim "Tests to Avoid" list (framework entry points such as activities / fragments / services should not have…

Its SKILL.md is about 4.6k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Testing & QA, covering Test generation and Unit testing. It works with Android. The repository describes itself as: ⚡️ A set of skills for Android testing: Compose UI, AndroidX Test, JVM unit tests, and ADB. The licence is Apache-2.0.

When your agent uses it

  • The user asks what should I write tests for
  • Should I unit-test this Activity
  • Do I need a test for this util class
  • What edge cases am I missing

Example prompts

  • “s five-category state vocabulary plus the explicit”
  • “s verbatim”
  • “what should I write tests for”
  • “/choosing-what-to-test”

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. State on screen — what the user observes right now
  2. State held in memory — ViewModel and presenter state
  3. Persisted state — DB, DataStore, SharedPreferences, files
  4. Other state — system bars, system services, alarms, broadcasts
  5. Errors and edge cases

What it can do on your machine

Read from SKILL.md and the folder at commit 8665ed5. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are kotlin).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Choosing What To Test loads about 4.6k tokens when it runs. Until then it costs about 201 tokens; SKILL.md has 1,526 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~201
When it runs · the whole SKILL.md, loaded when a task matches
~4.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from skydoves/android-testing-skills at commit 8665ed5, republished under its Apache-2.0 licence (© skydoves). 1,526 words, ~4,578 tokens.

Download SKILL.mdSave it as .claude/skills/choosing-what-to-test/SKILL.md (or your agent's skills folder).
name
choosing-what-to-test
description
Use this skill to pick which behaviors to cover in an Android test suite using Google's five-category state vocabulary plus the explicit "what NOT to test" list from `/training/testing/fundamentals/what-to-test`. Covers state on screen, state held in memory (ViewModels), persisted state (DB / DataStore / files), other state (system bars / system services), and errors / edge cases. Includes Google's verbatim "Tests to Avoid" list (framework entry points such as activities / fragments / services should not have business logic) and an edge-case mining checklist. Use when the user asks "what should I write tests for", "should I unit-test this Activity", "do I need a test for this util class", "what edge cases am I missing", or "should I test the ViewModel or the Composable".
license
Apache-2.0. See LICENSE for complete terms.
metadata.author
Jaewoong Eum (skydoves)
metadata.keywords
android-testing, what-to-test, test-coverage, viewmodel-tests, data-layer-tests, edge-cases, tests-to-avoid, ui-tests, compose-testing, test-strategy

Choosing What to Test — Cover State, Skip Framework Entry Points

Android test suites under-cover business logic and over-cover framework glue. Google's /training/testing/fundamentals/what-to-test page sorts test value by what state the code touches and explicitly names the categories of tests to avoid. This skill encodes those categories and the edge-case checklist so the agent can advise concretely instead of saying "test everything important".

When to use this skill

  • The user asks "what should I write tests for in this module" or "do I need a test for X".
  • The user asks whether to unit-test an Activity, Fragment, or Service (answer: usually no — see "What NOT to test").
  • The user is reviewing a PR and the test gap is unclear.
  • The user asks "what edge cases am I missing for this function".
  • The user asks where the testing effort should land between ViewModel, Repository, and Composable.

When NOT to use this skill

  • The user already knows what to test and is choosing the test scope (small/medium/big) — use ../understanding-the-testing-pyramid/SKILL.md.
  • The user is choosing between fakes / mocks / stubs — use ../../doubles/picking-test-doubles/SKILL.md.
  • The user is wiring source sets (src/test/ vs src/androidTest/) — use ../../strategies/organizing-test-source-sets/SKILL.md.

Prerequisites

  • A module with at least one ViewModel, repository, or screen.
  • Familiarity with the Android architecture layers (UI / Domain / Data) so the agent can map "data layer" to a real path.
  • The 3-layer pyramid framing from ../understanding-the-testing-pyramid/SKILL.md.

Five categories of state to cover

The five state categories below are the synthesis the user asked for. They map onto the verbatim sections of developer.android.com/training/testing/fundamentals/what-to-test (the page itself uses layer-style headers — "Essential unit tests", "UI tests", "Testing Edge Cases" — but the underlying axis is what kind of state changes).

1. State on screen — what the user observes right now

What is rendered: a button label, a list count, an enabled/disabled state, a checkbox toggle. Tested via UI tests:

"Screen UI tests check critical user interactions in a single screen. They perform actions such as clicking on buttons, typing in forms, and checking visible states. One test class per screen is a good starting point." — developer.android.com/training/testing/fundamentals/what-to-test

"User flow tests or Navigation tests, covering most common paths. These tests simulate a user moving through a navigation flow." — developer.android.com/training/testing/fundamentals/what-to-test

For Compose: assert via onNodeWithTag(...).assertIsDisplayed() / assertTextEquals(...) / assertIsEnabled(). For Views: onView(...).check(matches(isDisplayed())). Use the cross-category skill ../../../instrumentation/espresso/writing-espresso-tests/SKILL.md.

2. State held in memory — ViewModel and presenter state

ViewModel.uiState, in-memory caches, the current selection. Tested via small unit tests:

"Unit tests for ViewModels, or presenters." — developer.android.com/training/testing/fundamentals/what-to-test

A ViewModel test launches the ViewModel with a fake repository, drives an event, and asserts on the exposed StateFlow / LiveData. See ../../../jvm-tests/coroutines/testing-coroutines-with-runtest/SKILL.md and ../../../jvm-tests/coroutines/testing-flows-with-turbine/SKILL.md.

3. Persisted state — DB, DataStore, SharedPreferences, files

What survives process death:

"Unit tests for the data layer, especially repositories. Most of the data layer should be platform-independent. Doing so enables test doubles to replace database modules and remote data sources in tests." — developer.android.com/training/testing/fundamentals/what-to-test

Two flavors:

  • Repository unit tests — fake the storage source; verify the repository's caching, mapping, error handling.
  • Storage integration tests — exercise Room / DataStore / SharedPreferences with their real implementations. These are small instrumented tests per /fundamentals ("Small instrumented test: You can verify that your code works well with a framework feature, such as a SQLite database").
4. Other state — system bars, system services, alarms, broadcasts

Window-insets state, dark-mode flag, alarm scheduling, background-job state. The /what-to-test page does not give this its own header but the /fundamentals page covers it under instrumented tests. Test via Robolectric (medium-local) when shadows exist, or instrumented tests when the real system is required.

5. Errors and edge cases

"Unit tests should focus on both normal and edge cases. Edge cases are uncommon scenarios that human testers and larger tests are unlikely to catch. Examples include the following:

  • Math operations using negative numbers, zero, and boundary conditions.
  • All the possible network connection errors.
  • Corrupted data, such as malformed JSON.
  • Simulating full storage when saving to a file.
  • Object recreated in the middle of a process (such as an activity when the device is rotated)." — developer.android.com/training/testing/fundamentals/what-to-test

This is the highest-value column in any test budget — humans miss these, big tests miss these, and a small fake-driven unit test catches them in 5 ms.

What NOT to test (verbatim)

The page is unusually direct here:

"Some unit tests should be avoided because of their low value:

  • Tests that verify the correct operation of the framework or a library, not your code.
  • Framework entry points such as activities, fragments, or services should not have business logic so unit testing shouldn't be a priority. Unit tests for activities have little value, because they would cover mostly framework code and they require a more involved setup. Instrumented tests such as UI tests can cover these classes." — developer.android.com/training/testing/fundamentals/what-to-test

Operational consequences:

  • MUST NOT write Robolectric unit tests of an Activity's onCreate to assert that views are inflated. That is testing the framework.
  • MUST NOT write a unit test of RoomDatabase.Builder's migration registration. That tests Room.
  • MUST NOT write a unit test that mocks Retrofit to assert that @GET paths resolve. That tests Retrofit.
  • MUST NOT test private implementation details that change every refactor. Test public observable behavior.
  • PREFERRED: when a class is hard to unit-test, refactor business logic out of it (Activity → ViewModel → UseCase → Repository) — the page closes the loop with "With a testable app architecture, the code follows a structure that allows you to easily test different parts of it in isolation." (cited from /fundamentals).

The page also flags additional categories briefly:

"There are more specialized tests such as screenshot tests, performance tests, and monkey tests." — developer.android.com/training/testing/fundamentals/what-to-test

These are out of scope for the "what to test" decision but should be mentioned when the user asks about visual regressions or render correctness — see the cross-category skill ../../../compose/audit/auditing-compose-test-suite/SKILL.md.

Show full SKILL.md (583 more words)Show less

Patterns

Pattern: WRONG vs RIGHT — testing an Activity instead of its ViewModel
kotlin
// WRONG
@RunWith(AndroidJUnit4::class)
class CheckoutActivityTest {
    @get:Rule val rule = ActivityScenarioRule(CheckoutActivity::class.java)

    @Test fun whenTotalIsNegative_showsError() {
        rule.scenario.onActivity { activity ->
            activity.viewModel.applyCoupon("FREE_BEER_NEGATIVE_PRICE")
            // assert on the activity's TextView contents
            assertEquals("Error", activity.findViewById<TextView>(R.id.error).text)
        }
    }
}
// WRONG because: the test rebuilds the framework lifecycle, the Activity, the inflater,
// and the View graph just to assert business logic that lives in the ViewModel. Per
// /what-to-test: "Unit tests for activities have little value, because they would cover
// mostly framework code".
kotlin
// RIGHT — small, JVM, sub-50 ms
class CheckoutViewModelTest {
    @Test fun applyCoupon_negativePrice_emitsError() = runTest {
        val vm = CheckoutViewModel(FakePricingRepository(allowNegative = true))
        vm.applyCoupon("FREE_BEER_NEGATIVE_PRICE")
        assertEquals(CheckoutUiState.Error("Negative total"), vm.uiState.value)
    }
}

The Activity still gets a thin big-test (Espresso / Compose-test) that asserts the error string is rendered. The logic lives in the ViewModel test. Two layers, two responsibilities.

Pattern: WRONG vs RIGHT — over-mocking a util class
kotlin
// WRONG
class FormatDurationTest {
    private val clock = mockk<Clock>()
    private val locale = mockk<Locale>()
    @Test fun formatsMinutesAndSeconds() {
        every { clock.now() } returns Instant.parse("2024-01-01T00:01:30Z")
        every { locale.language } returns "en"
        assertEquals("1m 30s", formatDuration(90.seconds, clock, locale))
    }
}
// WRONG because: this is a pure-function utility per /what-to-test ("Unit tests for
// utility classes such as string manipulation and math"). Mocks add ceremony with
// no value. Pass real values.
kotlin
// RIGHT
class FormatDurationTest {
    @Test fun formatsMinutesAndSeconds() {
        assertEquals("1m 30s", formatDuration(90.seconds))
    }

    @Test fun handlesZero() {
        assertEquals("0s", formatDuration(0.seconds))
    }

    @Test fun handlesHoursBoundary() {
        assertEquals("1h 0m 0s", formatDuration(3600.seconds))
    }
}
Pattern: WRONG vs RIGHT — skipping the edge cases checklist
kotlin
// WRONG — only the happy path
class ParseAmountTest {
    @Test fun parsesValidAmount() = assertEquals(12.34, parseAmount("12.34"))
}
kotlin
// RIGHT — edge cases per /what-to-test
class ParseAmountTest {
    @Test fun parsesValidAmount() = assertEquals(12.34, parseAmount("12.34"))
    @Test fun parsesZero() = assertEquals(0.0, parseAmount("0"))
    @Test fun parsesNegative() = assertEquals(-5.0, parseAmount("-5"))
    @Test fun parsesScientific() = assertEquals(1e6, parseAmount("1e6"))
    @Test fun rejectsEmpty() = assertNull(parseAmount(""))
    @Test fun rejectsMalformed() = assertNull(parseAmount("12.34.56"))
    @Test fun rejectsLeadingWhitespace() = assertNull(parseAmount(" 12"))
    @Test fun rejectsLocaleComma() = assertNull(parseAmount("12,34"))  // German format
    @Test fun handlesMaxDouble() = assertEquals(Double.MAX_VALUE, parseAmount("1.7976931348623157E308"))
}

Edge-case mining checklist

Run this checklist before declaring a unit-test pass complete. Items map to the verbatim list on /training/testing/fundamentals/what-to-test plus skydoves additions for Compose/coroutines code.

  • Numeric boundaries — zero, negative, Int.MAX_VALUE, Long.MIN_VALUE, Double.NaN, Double.POSITIVE_INFINITY.
  • Empty / single / many collections — emptyList(), listOf(x), lists with thousands of items.
  • Null — every nullable input. Even if the type system would refuse, deserialization can produce nulls (Moshi / kotlinx-serialization with coerceInputValues).
  • Malformed strings — empty, whitespace-only, length-1, length-MAX, non-ASCII, RTL text, emoji, ZWJ sequences, surrogate pairs.
  • Locale variation — German number format 12,34, Arabic digits ٠١٢, Turkish dotted-i.
  • Network errors — IOException, HTTP 4xx, HTTP 5xx, malformed JSON, truncated stream, timeout.
  • Storage errors — disk-full, permission-denied, corrupt SQLite, encrypted preference.
  • Process death / state restoration — "Object recreated in the middle of a process (such as an activity when the device is rotated)" per the page. Cover rememberSaveable, SavedStateHandle, Bundle-restore.
  • Concurrency — same operation from two coroutines, cancellation mid-flight, slow producer + fast consumer (use kotlinx-coroutines-test).
  • Time — DST transitions, leap seconds, midnight crossings, timezone changes, monotonic vs wall clock.
  • Configuration changes — dark mode flip, locale change, font scale at 1.5x and 2.0x, RTL layout.

The first half is straight from Google's verbatim list; the second half is operational extension for modern Android.

Decision matrix — should this code have a test?

What does the code touch?                              Test? Where?
-----------------------------------------------------------------------------
Pure function / utility (string, math, mapping)        YES   src/test/ (small)
ViewModel / presenter state                            YES   src/test/ (small)
Repository / use case (fake the storage)               YES   src/test/ (small)
Real Room / DataStore                                  YES   src/androidTest/ (small instrumented)
Composable rendering of state                          YES   src/androidTest/ or src/test/ (Robolectric)
Navigation flow (multi-screen)                         YES   src/androidTest/ (big)
Activity onCreate / inflation logic                    NO    framework code
Fragment onViewCreated wiring                          NO    framework code
Service onStartCommand wiring                          NO    framework code
Retrofit interface (annotation routing)                NO    library code
Hilt module declarations                               NO    library code
Compose Modifier internals                             NO    library code
Generated code                                         NO    generated
Private function with no public observable effect      NO    test the public caller

Mandatory rules

  • MUST test public observable behavior (state exposed by ViewModel, return values of Repository, rendered semantics) — never private internals.
  • MUST NOT unit-test framework entry points (Activity, Fragment, Service) for business logic; refactor the logic out instead. Per /what-to-test: "framework entry points ... should not have business logic so unit testing shouldn't be a priority".
  • MUST cover edge cases from the verbatim list before merging: numeric boundaries, network errors, malformed data, full storage, process recreation.
  • MUST NOT verify framework or third-party library behavior. "Tests that verify the correct operation of the framework or a library, not your code" is on the explicit avoid list.
  • PREFERRED: keep one Compose / Espresso big-test per screen for "state on screen" coverage; lean on small ViewModel tests for everything else.
  • PREFERRED: when a class resists testing, treat that as an architecture signal — the production code is doing too many things or holds state in the wrong layer.

Verification

  • Every public function on every ViewModel and Repository in the module has at least one small test.
  • Every screen has at least one big or medium test asserting "state on screen" via assertIsDisplayed / check(matches(isDisplayed())).
  • No test class targets only an Activity / Fragment / Service to assert framework-handled behavior.
  • The edge-case checklist above is reviewed for every new public function with non-trivial input domain.
  • No test mocks Retrofit, Room, Hilt, or Compose internals to verify their behavior.
  • PR template (or review checklist) requires "what state does this code touch" to be answered before merge.

References

  • developer.android.com/training/testing/fundamentals/what-to-test — the canonical source for every quote in this skill.
  • developer.android.com/training/testing/fundamentals — testable architecture rationale, "Not all unit tests are local" quote.
  • developer.android.com/training/testing/local-tests — "Caution: Complex mocks should be avoided. Instead, you can use different types of test doubles such as fakes".
  • developer.android.com/training/testing/instrumented-tests — when state-on-screen tests must be instrumented vs Robolectric.
  • tasks/research/R8-android-fundamentals.md — verbatim "Essential unit tests" / "Testing Edge Cases" / "Unit Tests to Avoid" excerpts.
  • Sibling skills: ../understanding-the-testing-pyramid/SKILL.md, ../../doubles/picking-test-doubles/SKILL.md, ../../strategies/applying-testing-strategies/SKILL.md, ../../strategies/organizing-test-source-sets/SKILL.md.
  • Cross-category: ../../../jvm-tests/coroutines/testing-coroutines-with-runtest/SKILL.md, ../../../jvm-tests/coroutines/testing-flows-with-turbine/SKILL.md, ../../../jvm-tests/mocking/mocking-with-mockito/SKILL.md, ../../../jvm-tests/mocking/mocking-with-mockk/SKILL.md, ../../../instrumentation/espresso/writing-espresso-tests/SKILL.md, ../../../instrumentation/scenarios/launching-activities-with-activityscenario/SKILL.md, ../../../instrumentation/scenarios/launching-fragments-with-fragmentscenario/SKILL.md, ../../../compose/audit/auditing-compose-test-suite/SKILL.md.

© skydoves, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in fundamentals/concepts/choosing-what-to-test of skydoves/android-testing-skills.

Open the folder on GitHubat commit 8665ed5

Compare with similar skills

Choosing What To Test next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Choosing What To Test compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Choosing What To Test this skillskydoves/android-testing-skills334—~4.6kAutomated safety check: PassApache-2.0
Adk Verify Snippetsgoogle/adk-python22k—~1.4kAutomated safety check: PassApache-2.0
Hermetic Python Unit TestsdimensionalOS/dimos4.6k—~1.4kAutomated safety check: PassCustom licence
OpenROAD Module Test AdderThe-OpenROAD-Project/OpenROAD3.2k—~1.8kAutomated safety check: PassBSD-3-Clause
Testing SkillTypeCellOS/BlockNote10k—~2.6kAutomated safety check: PassCustom licence
Mesh Labpermissionlesstech/bitchat-android7.8k—~2.9kAutomated safety check: PassGPL-3.0

Similar skills

  • Adk Verify Snippets

    google/adk-python

    Official

    Checks that every Python code block in a Markdown file actually compiles and runs, by extracting each block to a temporary file, executing it in an isolated subprocess, and writing a pass/fail…

    22k GitHub stars~1.4k tokensUpdated today
    Testing & QAAuto-check passed

  • Hermetic Python Unit Tests

    dimensionalOS/dimos

    Rules for writing, fixing and reviewing pytest unit tests that are hermetic: behavior-focused, deterministic, isolated and cheap to run.

    4.6k GitHub stars~1.4k tokensUpdated today
    Testing & QAAuto-check passed

  • OpenROAD Module Test Adder

    The-OpenROAD-Project/OpenROAD

    Adds integration or unit tests to an OpenROAD module: writes the Tcl test, generates golden files and registers it in both CMake and Bazel.

    3.2k GitHub stars~1.8k tokensUpdated today
    Testing & QAAuto-check passed

  • Testing Skill

    TypeCellOS/BlockNote

    Instructions for writing, running, and updating unit/end-to-end tests.

    10k GitHub stars~2.6k tokensUpdated yesterday
    Testing & QAAuto-check passed

  • Mesh Lab

    permissionlesstech/bitchat-android

    Run, diagnose, and extend bitchat Android Mesh Lab physical-device tests.

    7.8k GitHub stars~2.9k tokensUpdated 4 days ago
    Testing & QAAuto-check passed

  • Concept Page Test Writer

    leonardomso/33-js-concepts

    Generates Vitest tests for every runnable code example on a JavaScript concept documentation page, following a four-phase extraction and conversion process.

    67k GitHub stars~5.5k tokensUpdated 29 days ago
    Testing & QAAuto-check passed

More from skydoves/android-testing-skills

All 50 skills in this repo

  • Asserting Bounds And Dimensions

    skydoves/android-testing-skills

    A skill your agent uses to verify Compose layout measurements from a UI test using assertWidthIsEqualTo, assertHeightIsEqualTo, assertWidthIsAtLeast, assertHeightIsAtLeast…

    334 GitHub stars~3.3k tokensUpdated 4 mo ago
    Auto-check passed

  • Asserting Node State And Text

    skydoves/android-testing-skills

    A skill your agent uses to verify a Compose semantics node's properties from a UI test using assertExists, assertDoesNotExist, assertIsDisplayed, assertIsNotDisplayed, assertIsDeactivated…

    334 GitHub stars~3.6k tokensUpdated 4 mo ago
    Auto-check passed

  • Capturing Preview Screenshots In CI

    skydoves/android-testing-skills

    A skill your agent uses to render every Jetpack Compose @Preview as a screenshot on a real Android device or emulator and publish a browsable HTML catalog from CI.

    334 GitHub stars~4.5k tokensUpdated 4 mo ago
    Auto-check: notes

  • Capturing Screenshots And Screenrecord

    skydoves/android-testing-skills

    A skill your agent uses to capture visual artefacts from a device for test failures, golden image generation, QA repro, and demo videos.

    334 GitHub stars~3.7k tokensUpdated 4 mo ago
    Auto-check passed

  • Choosing Test Rule Vs Runtest

    skydoves/android-testing-skills

    A skill your agent uses to pick the correct Compose UI test entry point.

    334 GitHub stars~4.5k tokensUpdated 4 mo ago
    Auto-check passed

  • Clicking And Scrolling

    skydoves/android-testing-skills

    A skill your agent uses to drive Jetpack Compose UI from tests with the high-level action APIs that do not go through a gesture builder — performClick, performScrollTo, performScrollToIndex…

    334 GitHub stars~3.6k tokensUpdated 4 mo ago
    Auto-check passed

Works with

Categories

Questions about Choosing What To Test

What does Choosing What To Test do?

A skill your agent uses to pick which behaviors to cover in an Android test suite using Google's five-category state vocabulary plus the explicit "what NOT to test" list from…. Choosing What To Test is an agent skill from skydoves/android-testing-skills. Use this skill to pick which behaviors to cover in an Android test suite using Google's five-category state vocabulary plus the explicit "what NOT to test" list from /training/testing/fundamentals/what-to-test.

When should I use Choosing What To Test?

Choosing What To Test fits situations like: the user asks what should I write tests for; should I unit-test this Activity; do I need a test for this util class; what edge cases am I missing.

How do I install Choosing What To Test in Claude Code?

Run `npx skills add skydoves/android-testing-skills --skill choosing-what-to-test -a claude-code`. Or copy the skill folder (fundamentals/concepts/choosing-what-to-test in skydoves/android-testing-skills) into .claude/skills/choosing-what-to-test in your project. Claude Code loads it when a task matches its description.

How do I install Choosing What To Test in Codex?

Run `npx skills add skydoves/android-testing-skills --skill choosing-what-to-test -a codex`. Or copy the skill folder (fundamentals/concepts/choosing-what-to-test in skydoves/android-testing-skills) into .agents/skills/choosing-what-to-test in your project. Codex loads it when a task matches its description.

Can I use Choosing What To Test in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add skydoves/android-testing-skills --skill choosing-what-to-test -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/choosing-what-to-test, .gemini/skills/choosing-what-to-test, .github/skills/choosing-what-to-test and .opencode/skills/choosing-what-to-test in your project.

What does Choosing What To Test need to run?

SKILL.md names no scripts, command-line tools or credentials: Choosing What To Test is instructions for the agent only.

Does Choosing What To Test access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Choosing What To Test safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Choosing What To Test use?

Choosing What To Test is published under the Apache-2.0 licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Choosing What To Test use?

About 4.6k tokens (SKILL.md is roughly 18k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Choosing What To Test?

Skills that share tags, products or a category with Choosing What To Test: Adk Verify Snippets (google/adk-python, 22k stars), Hermetic Python Unit Tests (dimensionalOS/dimos, 4.6k stars), OpenROAD Module Test Adder (The-OpenROAD-Project/OpenROAD, 3.2k stars) and Testing Skill (TypeCellOS/BlockNote, 10k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Choosing What To Test?

skydoves (a GitHub user) maintains it in skydoves/android-testing-skills, which has 334 GitHub stars. The repository holds 50 skills in this directory. The repository was last updated on May 25, 2026.

Source: skydoves/android-testing-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.