Efficient testing UI Android apps by example
summary
Explains concrete tactics: use Layout Inspector for app-only views and UI Automator Viewer for system-wide views, prefer Espresso with custom idling resources to avoid brittle sleeps, and avoid the generated recorder output because Espresso Test Recorder generates unmaintainable code. Adopt a robot-pattern internal DSL so DSL + robot pattern makes tests readable, start true end-to-end regressions from the splash screen with 10–20 core scenarios, use UI tests with mocking (about 40% faster in examples), and treat flaky tests by retrying failed runs three times and converting bugs into tests.
AI-written summary · about
chapters (11)
- 0:00Introduction to UI testing
- 3:40Local vs instrumentation tests
- 10:03Espresso test recorder limitations
- 13:41Espresso synchronization issues
- 16:53End-to-end vs UI tests with mocking
- 21:55Causes of flaky tests
- 25:55Naming and organizing tests
- 30:12Prioritizing test cases
- 33:41Writing tests from specification
- 35:28Efficiency in test design
- 43:03Q&A on flakiness and cross-platform testing
related talks
46mEfficient Android UI Testing
33mAndroid UI Testing & Challenges
44mTaking care of your UI tests
42mEfficient UI testing in Android
43mAndroid Apps Testing in 2019
38mThe Testing Pyramid – What does it mean for Android?
53mSolving Espresso Android Autotest Issues in the Real World
49mSolving the Problems of Espresso Android Autotests in the Real World