Jetpack Compose
Black-box testing for Jetpack Compose via AccessibilityService. Prioritizes text-based matching and semantics over testTag for refactoring resilience.

Maestro follows a fundamental principle: UI-level automation without framework intrusion. Unlike instrumentation-based tools such as Espresso or Robolectric, which execute inside the app process and depend on framework-specific APIs, Maestro operates externally using Android’s system automation interfaces. This allows Maestro to perform reliable black-box testing regardless of whether your UI is implemented with XML Views, Jetpack Compose, or other UI frameworks.
Architecture-agnostic testing philosophy
Maestro interacts with your application the same way the Android system and users do, using accessibility metadata and system-level automation. This provides several key advantages:
Framework independence: Maestro does not depend on Compose internals such as composition state, recomposition cycles, or render tree structure. Tests remain valid regardless of UI implementation details.
System-level element discovery: Maestro locates elements using accessibility metadata, visible text, resource identifiers, and other stable attributes exposed by the Android system. This ensures compatibility with Compose, XML Views, and hybrid applications.
Stable selector model: Element identification relies on externally observable properties such as visible text, accessibility labels (
contentDescription), and resource IDs, rather than internal framework constructs.
Refactoring resilience
Maestro tests are designed to validate user workflows rather than internal implementation details. This provides strong resilience during UI refactoring, including migration from XML-based layouts to Jetpack Compose.
Semantic stability: As long as visible text, accessibility metadata, or resource identifiers remain consistent, existing Maestro tests typically continue to work without modification.
Implementation independence: Tests verify behavior from the user’s perspective, protecting against failures caused by internal architectural changes that do not affect the user experience.
Element interaction patterns
Maestro interacts with UI elements using selectors based on system-exposed properties rather than framework-specific APIs.
Element selection strategy
Maestro supports multiple stable selector types, including:
Visible text
Matches elements displaying the specified text.
Accessibility labels
Elements with accessibility metadata such as:
can be targeted directly:
Resource identifiers
When available, resource IDs provide highly stable selectors:
These selector strategies work consistently across Compose and View-based interfaces.
Compatibility with Jetpack Compose semantics
Jetpack Compose exposes accessibility metadata through its semantics system. Maestro automatically uses this information when available, including:
Visible text from composables such as
TextandButtonAccessibility descriptions defined with
contentDescriptionResource identifiers when provided
This enables reliable interaction without requiring Compose-specific test APIs or instrumentation.
Comparative advantages
Execution model
External (black-box)
In-process (white-box)
Framework dependency
None
High
Compose internals required
No
Yes
Test infrastructure in app
Not required
Required
Refactoring resilience
High (when semantics remain stable)
Moderate to low
Accessibility usage
Recommended for reliability
Optional
Maestro eliminates the need for app-side test infrastructure code, lowering barriers for QA practitioners lacking native Android development expertise.
Next steps
If you don't know how to create tests with Maestro, access the QuickStart guide to get up and running in minutes.
To learn how to create tests, refer to the Flows documentation. If you want to explore Maestro solutions, consult the appropriate documentation:
Last updated