Rock-Solid UI and Instrumentation Testing
summary
Concrete recipe for reliable Espresso UI tests: build a multi-module test setup so feature teams compile and run tests in isolation, use a robot DSL like Kakao/Kakao DSL to hide Espresso calls, register idling resources (Jake Wharton’s HTTP idling, RxIdler for RxJava) and mockwebserver or mocked Retrofit, inject controllable executors instead of letting libraries spawn thread pools, disable animations, avoid Thread.sleep, and shard runs with Flank + Firebase. Result: a 1,000+ test suite that runs in parallel and finishes under 20 minutes in CI; coroutines still lack a turnkey idling solution.
AI-written summary · about
chapters (21)
- 0:00Introduction and setup
- 1:13UI testing at scale
- 2:42User interaction vs UI tests
- 5:53Challenges with Espresso
- 7:19Robot pattern for readability
- 10:57Device and sync issues
- 12:01Disabling animations
- 14:10Thread sleep pitfalls
- 16:40Idling resources explained
- 19:08Legacy app example
- 23:05Thread pool control
- 25:14Coroutines testing gap
- 26:16Architecture components
- 27:58Data binding delays
- 30:24List adapter issues
- 32:08Compose testing limits
- 33:12Device farm setup
- 35:01Test sharding benefits
- 36:49Multi-module testing
- 39:17Future of Android testing
- 41:00Q&A and closing
related talks
44mRock-Solid UI and Instrumentation Testing
42mZero to hero in UI testing
44mDrink Espresso during Android Testing
23mManaging your UI tests simply and effectively
40mThe Importance of Being Tested
46mEfficient Android UI Testing
53mSolving Espresso Android Autotest Issues in the Real World
43mUI testing is so easy - said no developer ever