The Testing Pyramid – What does it mean for Android?
summary
Argues that adding lots of small UI unit tests — rendering view states with a mocked presenter and checking tags/content descriptions — catches UI bugs faster than sparse end‑to‑end suites. Uses JUnit + Mockito + Espresso for these tests, suggests Spec for clearer given/when/then naming, and always mocks network calls. Example: 38 widget UI unit tests run in ~16–17s (avg <0.5s each) versus two end‑to‑end checks in ~6s (avg ~1.5s), claiming roughly 300x speedup for equivalent assertions.
AI-written summary · about
chapters (18)
- 0:00Introduction
- 1:40Why write tests
- 5:58The Testing Pyramid
- 13:18Unidirectional Data Flow
- 16:58Kotlin Data Classes
- 19:08UI Unit Test
- 21:53EndtoEnd Tests
- 24:38Unit Tests
- 26:03Spec
- 27:10JUnit
- 28:05Spec Tests
- 29:18Summary
- 30:00Android module UI tests
- 30:59Questions
- 31:13Do UI Unit Tests work with Roboelectric
- 31:36Can UI Unit Tests test content descriptions
- 32:22When should we mock network calls
- 33:33Real questions
related talks
44mEfficient testing UI Android apps by example
43mUI testing is so easy - said no developer ever
46mEfficient Android UI Testing
42mEfficient UI testing in Android
45mWhere do the Android tests belong?
34mSetting up Android UI Testing on CI
31mFurther Speeding Up UI Tests (Espresso)
56mTesting for Success in the Real World