Agent skill

Structuring A Compose Test

by skydoves in skydoves/android-testing-skills

A skill your agent uses to structure a Jetpack Compose UI test class the way androidx itself writes them — @MediumTest + @RunWith(AndroidJUnit4::class), a single…

Apache-2.0Auto-check passedMobile

Install Structuring A Compose Test

skills CLI
$ npx skills add skydoves/android-testing-skills --skill structuring-a-compose-test -a claude-code

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

GitHub CLI
$ gh skill install skydoves/android-testing-skills structuring-a-compose-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/compose/patterns/structuring-a-compose-test .claude/skills/structuring-a-compose-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
structuring-a-compose-test
GitHub stars
333
Token cost
~3.6k tokens
SKILL.md length
820 words
Files
1
Skills in repo
50
Repo updated
First seen
Licence
Apache-2.0

At a glance

A skill your agent uses to structure a Jetpack Compose UI test class the way androidx itself writes them — @MediumTest + @RunWith(AndroidJUnit4::class), a single…

  • Structure a Jetpack Compose UI test class the way androidx itself writes them — @MediumTest + @RunWith(AndroidJUnit4::class)
  • SKILL.md covers When to use this skill, When NOT to use this skill, Prerequisites and Workflow, plus 4 more sections
  • Reaches schemas.android.com
  • A single createComposeRule(StandardTestDispatcher()) rule

What it does

Structuring A Compose Test is an agent skill from skydoves/android-testing-skills. Use this skill to structure a Jetpack Compose UI test class the way androidx itself writes them — @MediumTest + @RunWith(AndroidJUnit4::class), a single createComposeRule(StandardTestDispatcher()) rule, hoisted mutableStateOf declared above setContent { }, and the Test → Find → Assert → Act → Re-assert flow. Covers when to use createAndroidComposeRule<MyActivity() for custom Activities, how to drive state from outside the composition via runOnIdle { }, why state must NOT be hoisted inside setContent, and why…

Its SKILL.md is about 3.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 Mobile, covering Android development. It works with Android, Jetpack Compose and Kotlin. 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

  • Structure a Jetpack Compose UI test class the way androidx itself writes them — @MediumTest + @RunWith(AndroidJUnit4::class)
  • A single createComposeRule(StandardTestDispatcher()) rule
  • Hoisted mutableStateOf declared above setContent { }
  • The Test → Find → Assert → Act → Re-assert flow

Example prompts

  • “how do I write a Compose test”
  • “where do I declare state”
  • “how do I name the test class”
  • “/structuring-a-compose-test”

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 and xml).

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

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • schemas.android.com

    Also links to:

    • developer.android.com

    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

Structuring A Compose Test loads about 3.6k tokens when it runs. Until then it costs about 229 tokens; SKILL.md has 820 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~229
When it runs · the whole SKILL.md, loaded when a task matches
~3.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). 820 words, ~3,599 tokens.

Download SKILL.mdSave it as .claude/skills/structuring-a-compose-test/SKILL.md (or your agent's skills folder).
name
structuring-a-compose-test
description
Use this skill to structure a Jetpack Compose UI test class the way androidx itself writes them — `@MediumTest` + `@RunWith(AndroidJUnit4::class)`, a single `createComposeRule(StandardTestDispatcher())` rule, hoisted `mutableStateOf` declared above `setContent { }`, and the Test → Find → Assert → Act → Re-assert flow. Covers when to use `createAndroidComposeRule<MyActivity>()` for custom Activities, how to drive state from outside the composition via `runOnIdle { }`, why state must NOT be hoisted inside `setContent`, and why `@get:Rule createComposeRule()` and `runComposeUiTest { }` MUST NOT both appear in the same test. Use when the developer asks "how do I write a Compose test", "where do I declare state", "how do I name the test class", "MediumTest vs LargeTest", "rule.setContent inside @Before", or shows a test class that won't compile or doesn't drive state from outside.
license
Apache-2.0. See LICENSE for complete terms.
metadata.author
Jaewoong Eum (skydoves)
metadata.keywords
jetpack-compose, ui-testing, compose-test-rule, createComposeRule, createAndroidComposeRule, test-class-skeleton, hoisted-state, runOnIdle, androidjunit4…

Structuring a Compose Test — The androidx-Canonical Class Skeleton

Compose tests fail or rot because their structure is wrong, not because the assertions are wrong. State that lives inside setContent { } cannot be driven from the test thread; setContent called inside @Before becomes a hidden race; combining @get:Rule with runComposeUiTest { } creates two competing test environments. This skill encodes the exact class skeleton used by androidx.compose.material3 and androidx.compose.foundation so the developer's tests behave the same way.

When to use this skill

  • The developer is creating a new *Test.kt and asks where to put state, the rule, and setContent.
  • A test compiles but cannot mutate state mid-test ("how do I flip the checkbox after the first assertion?").
  • The developer pasted setContent into @Before and the test is now flaky or will not start.
  • A reviewer flags a test for declaring state inside setContent { }.
  • The developer mixed @get:Rule createComposeRule() and runComposeUiTest { } and gets confusing failures.

When NOT to use this skill

  • The developer is choosing which entry point to use (rule vs. runComposeUiTest); use ../../setup/choosing-test-rule-vs-runtest/SKILL.md.
  • The build cannot resolve createComposeRule; use ../../setup/configuring-test-dependencies/SKILL.md.
  • The decision is host (Robolectric) vs. device (instrumentation); use ../../setup/setting-up-host-vs-device-tests/SKILL.md.
  • The test is specifically for a LazyColumn/LazyRow; layer ../testing-lazy-lists/SKILL.md on top of this skeleton.

Prerequisites

  • androidx.compose.ui:ui-test-junit4 on androidTestImplementation, androidx.compose.ui:ui-test-manifest on debugImplementation. See ../../setup/configuring-test-dependencies/SKILL.md.
  • Default activity is androidx.activity.ComponentActivity (provided by ui-test-manifest). For a custom Activity the androidTest source set MUST declare it in AndroidManifest.xml.
  • Kotlin source set: src/androidTest/kotlin/... (instrumentation) or src/test/kotlin/... (Robolectric host).

Workflow

  • 1. Mirror the production package. Place MyButtonTest.kt in the same package as MyButton.kt. The class name is <ProductionFile>Test (SwitchTest.kt, LazyListTest.kt).

  • 2. Annotate the class. @MediumTest is the default budget. Use @LargeTest only for tests that intentionally take seconds (long-clicks via performTouchInput { longClick() }, multi-second animations). @RunWith(AndroidJUnit4::class) is non-negotiable for instrumentation.

  • 3. Declare exactly one rule. Prefer the v2 entry point — it defaults the composition dispatcher to StandardTestDispatcher, matching kotlinx.coroutines.test.runTest.

kotlin
import androidx.compose.ui.test.junit4.v2.createComposeRule
import kotlinx.coroutines.test.StandardTestDispatcher

@MediumTest
@RunWith(AndroidJUnit4::class)
class MyButtonTest {
    @get:Rule val rule = createComposeRule(StandardTestDispatcher())
}

For a custom Activity (e.g. FragmentActivity, a screen-under-test Activity), use the reified v2 helper:

kotlin
import androidx.compose.ui.test.junit4.v2.createAndroidComposeRule
@get:Rule val rule = createAndroidComposeRule<FragmentActivity>(StandardTestDispatcher())

Cited from compose/foundation/foundation/src/androidDeviceTest/kotlin/androidx/compose/foundation/textfield/TextFieldFocusCustomDialogTest.kt:60.

  • 4. Hoist state ABOVE setContent. Anything the test wants to mutate or read must be a property declared in the test method, then captured by reference inside the composable.

  • 5. Call setContent { } INSIDE the @Test method, not in @Before. Each test owns its own composition. Tests with shared setContent in @Before cannot vary content between cases and lose the per-test state setup the framework expects.

  • 6. Follow Test → Find → Assert → Act → Re-assert. The canonical shape from compose/material3/material3/src/androidDeviceTest/kotlin/androidx/compose/material3/SwitchTest.kt:240-262 (the switch_stateChange_movesThumb test):

kotlin
@Test
fun switch_stateChange_movesThumb() {
    var checked by mutableStateOf(false)                          // STATE (hoisted)
    rule.setMaterialContent(lightColorScheme()) {                  // SET CONTENT (in test body)
        val spacer = @Composable { Spacer(Modifier.size(16.dp).testTag("spacer")) }
        Switch(
            modifier = Modifier.testTag(defaultSwitchTag),
            checked = checked,
            thumbContent = spacer,
            onCheckedChange = { checked = it },
        )
    }

    rule.onNodeWithTag("spacer", useUnmergedTree = true)           // FIND + ASSERT
        .assertLeftPositionInRootIsEqualTo(8.dp)

    rule.runOnIdle { checked = true }                              // ACT (mutate from outside)

    rule.onNodeWithTag("spacer", useUnmergedTree = true)           // RE-ASSERT
        .assertLeftPositionInRootIsEqualTo(28.dp)

    rule.runOnIdle { checked = false }
    rule.onNodeWithTag("spacer", useUnmergedTree = true).assertLeftPositionInRootIsEqualTo(8.dp)
}
  • 7. Read state from outside via rule.runOnIdle { … }. The block runs after waitForIdle(), so observed values reflect the latest composition.
kotlin
val (index, offset) = rule.runOnIdle {
    state.firstVisibleItemIndex to state.firstVisibleItemScrollOffset
}

Cited from compose/foundation/foundation/integration-tests/lazy-tests/src/androidTest/kotlin/androidx/compose/foundation/lazy/list/LazyListTest.kt:903-904.

  • 8. Write state from outside via rule.runOnIdle { … }. Direct assignment from the test thread races the recomposer.
kotlin
rule.runOnIdle { count = 5 }

Patterns

Pattern: state hoisted inside vs. above setContent
kotlin
// WRONG
@Test
fun toggle() {
    rule.setContent {
        var checked by remember { mutableStateOf(false) }   // <-- trapped inside composition
        Switch(checked = checked, onCheckedChange = { checked = it })
    }
    rule.runOnIdle { checked = true }                       // does not compile / has no reference
}
// WRONG because: the test thread has no reference to `checked`. The state cannot be driven
// from outside, and the test can only verify the very first frame.
kotlin
// RIGHT
@Test
fun toggle() {
    var checked by mutableStateOf(false)                    // <-- hoisted to test scope
    rule.setContent {
        Switch(checked = checked, onCheckedChange = { checked = it })
    }
    rule.onNodeWithTag("switch").assertIsOff()
    rule.runOnIdle { checked = true }                       // mutate via runOnIdle
    rule.onNodeWithTag("switch").assertIsOn()
}
Pattern: setContent in @Before
kotlin
// WRONG
@Before
fun setUp() {
    rule.setContent { MyScreen(state) }                     // <-- shared across all tests
}

@Test fun stateA() { /* mutate `state` here, but it was already composed without this case */ }
kotlin
// RIGHT
@Test
fun stateA() {
    val state = ScreenState(initial = "A")
    rule.setContent { MyScreen(state) }                     // <-- per-test composition
    rule.onNodeWithTag("title").assertTextEquals("A")
}
Pattern: one rule per class — never mix with runComposeUiTest
kotlin
// WRONG
class MyTest {
    @get:Rule val rule = createComposeRule(StandardTestDispatcher())

    @Test fun a() = runComposeUiTest {                      // <-- second test environment
        setContent { /* … */ }
    }
}
// WRONG because: createComposeRule and runComposeUiTest each manage an independent test
// environment (composition + MainTestClock + IdlingResourceRegistry). Mixing them produces
// undefined behavior. KDoc warns explicitly: see the ComposeUiTest.android.kt KDoc on
// runComposeUiTest, runAndroidComposeUiTest, runEmptyComposeUiTest, and the v2 variants.
kotlin
// RIGHT — pick exactly one entry point per class
class MyRuleTest {
    @get:Rule val rule = createComposeRule(StandardTestDispatcher())
    @Test fun a() { rule.setContent { /* … */ } }
}

// or
class MyFunctionTest {
    @Test fun a() = runComposeUiTest { setContent { /* … */ } }
}
Pattern: custom Activity needs its own manifest entry
kotlin
// RIGHT — ComponentActivity comes free from ui-test-manifest
@get:Rule val rule = createComposeRule(StandardTestDispatcher())
kotlin
// RIGHT — a custom Activity must be declared in src/androidTest/AndroidManifest.xml
@get:Rule val rule = createAndroidComposeRule<MyActivity>(StandardTestDispatcher())
xml
<!-- src/androidTest/AndroidManifest.xml -->
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
    <application>
        <activity android:name=".MyActivity" />
    </application>
</manifest>
Pattern: MediumTest vs LargeTest
kotlin
@MediumTest                     // default — sub-second tests
class SwitchTest { /* … */ }

@LargeTest                      // long-clicks, multi-second animations
class CombinedClickableTest { /* … */ }

@MediumTest is used by SwitchTest.kt:76 and most material3/foundation suites. @LargeTest is reserved for tests whose total wall time intentionally exceeds the medium budget.

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

Mandatory rules

  • MUST annotate the class with @RunWith(AndroidJUnit4::class) and a size annotation (@MediumTest by default).
  • MUST declare exactly one rule per class — either createComposeRule(...), createAndroidComposeRule<A>(...), or createEmptyComposeRule(). MUST NOT combine a @get:Rule rule with runComposeUiTest { } in the same class. KDoc cited at compose/ui/ui-test/src/androidMain/kotlin/androidx/compose/ui/test/ComposeUiTest.android.kt:158, 204, 247, 338.
  • MUST prefer the v2 entry points androidx.compose.ui.test.junit4.v2.createComposeRule / createAndroidComposeRule. The v1 forms are @Deprecated(level = WARNING) because they use UnconfinedTestDispatcher instead of StandardTestDispatcher (skydoves directive #6).
  • MUST hoist mutable state as var x by mutableStateOf(...) above setContent { } whenever the test must drive or observe it.
  • MUST call rule.setContent { } inside the @Test method. MUST NOT call it in @Before.
  • MUST mutate state from outside via rule.runOnIdle { state = … } (or rule.runOnUiThread { … } for cases where idling first is undesirable, e.g. mainClock.autoAdvance = false). See skydoves directive #5. Detail in ../../synchronization/synchronizing-with-idle/SKILL.md.
  • MUST read state from outside via rule.runOnIdle { state.value }. Direct reads from the test thread snapshot the wrong frame.
  • PREFERRED: find by Modifier.testTag(...) declared as a const in production (skydoves directive #1). Text finders are i18n-fragile. See ../../finders/finding-nodes-by-tag-text-content/SKILL.md.
  • PREFERRED: Test → Find → Assert → Act → Re-assert per logical state change. Multi-step tests stack additional Act → Re-assert pairs (SwitchTest.kt:140-147).

Verification

  • Class has @RunWith(AndroidJUnit4::class) + @MediumTest (or @LargeTest).
  • Exactly one @get:Rule declared and it is a createComposeRule(...) / createAndroidComposeRule(...) / createEmptyComposeRule() instance.
  • No runComposeUiTest { } invocation appears in the same class.
  • setContent { } appears inside @Test methods only — not in @Before / @BeforeEach.
  • Every state the test mutates is declared with var x by mutableStateOf(...) above setContent, captured by reference inside the composable.
  • All state mutations after setContent go through rule.runOnIdle { } or rule.runOnUiThread { }.
  • All cross-frame state reads happen inside rule.runOnIdle { }.
  • No Thread.sleep appears in the test method (skydoves directive #7). See ../../synchronization/synchronizing-with-idle/SKILL.md.
  • Custom Activities are declared in src/androidTest/AndroidManifest.xml (not just the production AndroidManifest.xml).

References

  • Compose testing overview: https://developer.android.com/develop/ui/compose/testing
  • Compose testing setup: https://developer.android.com/develop/ui/compose/testing#setup
  • Compose testing cheat sheet: https://developer.android.com/develop/ui/compose/testing-cheatsheet
  • Canonical class skeleton: compose/material3/material3/src/androidDeviceTest/kotlin/androidx/compose/material3/SwitchTest.kt:76-263
  • Custom Activity rule: compose/foundation/foundation/src/androidDeviceTest/kotlin/androidx/compose/foundation/textfield/TextFieldFocusCustomDialogTest.kt:57-60
  • v2 rule factory: compose/ui/ui-test-junit4/src/androidMain/kotlin/androidx/compose/ui/test/junit4/v2/AndroidComposeTestRule.android.kt
  • "Do not mix rule and runComposeUiTest" KDoc: compose/ui/ui-test/src/androidMain/kotlin/androidx/compose/ui/test/ComposeUiTest.android.kt:158, 204, 247, 338
  • runOnIdle semantics: compose/ui/ui-test-junit4/src/jvmAndAndroidMain/kotlin/androidx/compose/ui/test/junit4/ComposeTestRule.jvmAndAndroid.kt

© 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 compose/patterns/structuring-a-compose-test of skydoves/android-testing-skills.

Open the folder on GitHubat commit 8665ed5

Compare with similar skills

Structuring A Compose 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.

Structuring A Compose Test compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Structuring A Compose Test this skillskydoves/android-testing-skills333—~3.6kAutomated safety check: PassApache-2.0
Compose Multiplatform Patternsmonta-app/ocpp-emulator1805 repos~2kAutomated safety check: PassApache-2.0
Android Developmentdpconde/claude-android-skill336—~1.7kAutomated safety check: PassMIT
Claude Android NinjaDrjacky/claude-android-ninja124—~5.2kAutomated safety check: PassApache-2.0
Jetpack Composedarriousliu/PiPixiv262—~1.5kAutomated safety check: PassApache-2.0
Coding Stylesk2andy/candy-browser488—~548Automated safety check: PassMPL-2.0

Similar skills

  • Compose Multiplatform Patterns

    monta-app/ocpp-emulator

    Compose Multiplatform and Jetpack Compose patterns for KMP projects — state management, navigation, theming, performance, and platform-specific UI.

    180 GitHub starsUsed in 5 repos~2k tokens
    MobileAuto-check passed
  • Android Development

    dpconde/claude-android-skill

    Create production-quality Android applications following Google's official architecture guidance and NowInAndroid best practices.

    336 GitHub stars~1.7k tokensUpdated 10 mo ago
    MobileAuto-check passed
  • Claude Android Ninja

    Drjacky/claude-android-ninja

    Build and migrate Android apps with Kotlin, Jetpack Compose, MVVM, Hilt, Room 3 (KSP, SQLiteDriver, Flow/suspend DAOs), Navigation3, and multi-module Gradle.

    124 GitHub stars~5.2k tokensUpdated 9 days ago
    MobileAuto-check passed
  • Jetpack Compose

    darriousliu/PiPixiv

    Jetpack Compose expert skill for Android UI development. An agent skill from darriousliu/PiPixiv.

    262 GitHub stars~1.5k tokensUpdated today
    MobileAuto-check passed
  • Coding Style

    sk2andy/candy-browser

    Apply Candy Browser's project-specific Kotlin, Jetpack Compose, Android/WebView, testing, and generator conventions.

    488 GitHub stars~548 tokensUpdated yesterday
    MobileAuto-check passed
  • Compose Agent

    hamen/compose_skill

    Helps AI coding assistants write modern Jetpack Compose: correct state, side effects, performance-aware modifiers, Navigation 3, Paging 3 in Compose, coroutines on lifecycle, animations, UI tests…

    373 GitHub stars~4k tokensUpdated 2 mo ago
    MobileAuto-check: notes

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…

    333 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…

    333 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.

    333 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.

    333 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.

    333 GitHub stars~4.5k tokensUpdated 4 mo ago
    Auto-check passed
  • Choosing What To Test

    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…

    333 GitHub stars~4.6k tokensUpdated 4 mo ago
    Auto-check passed

Categories

Questions about Structuring A Compose Test

What does Structuring A Compose Test do?

A skill your agent uses to structure a Jetpack Compose UI test class the way androidx itself writes them — @MediumTest + @RunWith(AndroidJUnit4::class), a single…. Structuring A Compose Test is an agent skill from skydoves/android-testing-skills. Use this skill to structure a Jetpack Compose UI test class the way androidx itself writes them — @MediumTest + @RunWith(AndroidJUnit4::class), a single createComposeRule(StandardTestDispatcher()) rule, hoisted mutableStateOf declared above setContent { }, and the Test → Find → Assert → Act → Re-assert flow.

When should I use Structuring A Compose Test?

Structuring A Compose Test fits situations like: structure a Jetpack Compose UI test class the way androidx itself writes them — @MediumTest + @RunWith(AndroidJUnit4::class); A single createComposeRule(StandardTestDispatcher()) rule; hoisted mutableStateOf declared above setContent { }; the Test → Find → Assert → Act → Re-assert flow.

How do I install Structuring A Compose Test in Claude Code?

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

How do I install Structuring A Compose Test in Codex?

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

Can I use Structuring A Compose 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 structuring-a-compose-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/structuring-a-compose-test, .gemini/skills/structuring-a-compose-test, .github/skills/structuring-a-compose-test and .opencode/skills/structuring-a-compose-test in your project.

What does Structuring A Compose Test need to run?

SKILL.md names no scripts, command-line tools or credentials: Structuring A Compose Test is instructions for the agent only.

Does Structuring A Compose Test access the network?

SKILL.md names 2 domains. In commands or code: schemas.android.com; the agent is likely to contact it when it follows the instructions. As links in the text: developer.android.com. This is read from the text; nothing was executed.

Is Structuring A Compose 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 Structuring A Compose Test use?

Structuring A Compose 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 Structuring A Compose Test use?

About 3.6k tokens (SKILL.md is roughly 14k 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 Structuring A Compose Test?

Skills that share tags, products or a category with Structuring A Compose Test: Compose Multiplatform Patterns (monta-app/ocpp-emulator, 180 stars), Android Development (dpconde/claude-android-skill, 336 stars), Claude Android Ninja (Drjacky/claude-android-ninja, 124 stars) and Jetpack Compose (darriousliu/PiPixiv, 262 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Structuring A Compose Test?

skydoves (a GitHub user) maintains it in skydoves/android-testing-skills, which has 333 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.