android-testing-ui
Validate Android UI behavior with Compose UI tests, Espresso-style checks, accessibility assertions, and state coverage.
Android Testing UI
When To Use
- Use this skill when the request is about: android ui test, compose ui test screen, espresso validation android.
- Primary outcome: Validate Android UI behavior with Compose UI tests, Espresso-style checks, accessibility assertions, and state coverage.
- Handoff skills when the scope expands:
android-compose-accessibilityandroid-ui-states-validation
Workflow
- Scope the risk surface: correctness, security, performance, test depth, or release automation.
- Pick the narrowest verification strategy that still catches the likely regressions.
- Instrument the workflow so failures are actionable rather than just red.
- Run the relevant checks on the showcase apps and packaging outputs.
- Capture any residual risk with explicit follow-up work and owner skills.
Guardrails
- Prefer reproducible checks in CI over one-off local heroics.
- Fail with a precise remediation path instead of a vague quality gate.
- Keep secrets, signing material, and production credentials out of examples and fixtures.
- Treat performance and security work as engineering tasks with evidence, not folklore.
Anti-Patterns
- Adding more tests without increasing signal.
- Shipping benchmarks or security scans that no one can reproduce.
- Hard-coding release credentials into build logic.
- Using synthetic metrics with no user-impact interpretation.
Examples
Happy path
- Scenario: Run Compose UI assertions for the task board and action flows.
- Command:
cd examples/orbittasks-compose && ./gradlew :app:connectedDebugAndroidTest
Edge case
- Scenario: Validate XML screen behavior under configuration and content edge cases.
- Command:
cd examples/orbittasks-xml && ./gradlew :app:connectedDebugAndroidTest
Failure recovery
- Scenario: Separate UI-testing requests from UI-state reviews or accessibility-only prompts.
- Command:
python3 scripts/eval_triggers.py --skill android-testing-ui
Done Checklist
- The implementation path is explicit, minimal, and tied to the right Android surface.
- Relevant example commands and benchmark prompts have been exercised or updated.
- Handoffs to adjacent skills are documented when the request crosses boundaries.
- Official references cover the chosen pattern and the main migration or troubleshooting path.