Verified:Website 𝕏@github_skydoves GitHub

structuring-a-compose-test

Structure Jetpack Compose UI test classes with correct state and lifecycle patterns.

303|10|Updated May 15, 2026

Search Tags:#jetpack-compose #ui-testing #compose-test-rule #hoisted-state #runonidle #androidjunit4 #androidx-compose-test

Ready to run

npx skills add https://github.com/skydoves/android-testing-skills --skill structuring-a-compose-test

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: structuring-a-compose-test
Source: https://github.com/skydoves/android-testing-skills/tree/main/compose/patterns/structuring-a-compose-test
Command: npx skills add https://github.com/skydoves/android-testing-skills --skill structuring-a-compose-test

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill fixes flaky or uncompilable Jetpack Compose UI tests caused by incorrect class structure, incorrect rule/entry-point usage, and state being created inside setContent instead of being hoisted for the test to drive.

Core Features & Use Cases

Canonical test class skeleton: Enforces the androidx-style structure (typically @MediumTest, @RunWith(AndroidJUnit4::class), and a single createComposeRule(StandardTestDispatcher()) rule).
Correct state ownership and lifecycle: Keeps mutable state declared above setContent so the test can mutate and re-assert reliably using rule.runOnIdle.
Prevents incompatible patterns: Avoids mixing @get:Rule with runComposeUiTest { } and avoids calling setContent in @Before.
Custom Activity support: Uses createAndroidComposeRule<MyActivity>() when the screen-under-test is not a ComponentActivity-backed default.

Quick Start

Ask the AI: “Show me the androidx-canonical skeleton for a Compose UI test that hoists mutable state above setContent and mutates it via rule.runOnIdle, without mixing @get:Rule and runComposeUiTest.”

Frequently Asked Questions about structuring-a-compose-test

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

FAQPage Schema

How do I structure a Jetpack Compose UI test to avoid flaky state updates?▼

To avoid flaky Jetpack Compose UI tests, hoist mutableStateOf above setContent and perform all cross-frame reads and writes using rule.runOnIdle. This ensures the test correctly drives state mutations and re-asserts reliably.

Why does my Compose test fail when mixing createComposeRule and runComposeUiTest?▼

Mixing createComposeRule with runComposeUiTest causes failure because they are incompatible entry points. You must use exactly one v2 compose rule, such as createComposeRule or createAndroidComposeRule, and avoid mixing it with @get:Rule.

How do I test a Compose screen that requires a custom Activity?▼

To test a Compose screen requiring a custom Activity, use createAndroidComposeRule<MyActivity>() instead of the default rule. This is necessary when the screen-under-test is not backed by a default ComponentActivity.

When should I call setContent in an AndroidX Compose test?▼

You should call setContent inside the @Test method rather than in @Before. Calling setContent in @Before is an incompatible pattern that disrupts the composition lifecycle and leads to unstable test behavior.

What annotations do I need for a canonical AndroidX Compose test class?▼

A canonical AndroidX Compose test class requires @RunWith(AndroidJUnit4::class) and an appropriate size annotation like @MediumTest. This combination ensures the instrumentation test runs with the correct lifecycle and size constraints.

What is the correct workflow for asserting state changes in Compose UI testing?▼

The correct workflow for Compose UI testing is Test, Find, Assert, Act, and Re-assert. After hoisting mutable state above setContent, you mutate it via rule.runOnIdle and re-assert to verify the UI responds correctly.