The mobile testing strategy defines what is tested, at which layer, with which tools, and to which coverage threshold. A testing strategy that is too thin produces regressions in production. A testing strategy that is too heavy produces slow, brittle tests that engineers work around rather than with.
| 1 | Overview | 2 | Testing Pyramid Layers |
| 3 | Anti-Patterns to Avoid | 4 | References |
Mobile testing has five layers in the pyramid. The base (unit tests) contains the most tests, runs the fastest, and provides the most actionable feedback. The apex (E2E tests on physical devices) contains the fewest tests, runs the slowest, and is reserved for smoke testing of critical production paths. Investment follows the pyramid: most engineering effort in unit tests, least in E2E.
Tests Use Cases and ViewModels without any device, emulator, simulator, network, or database. Android: JUnit5 + Mockk (for mocking Kotlin interfaces) + Turbine (for testing Kotlin Flow/StateFlow emissions). iOS: XCTest + Swift Testing framework (Xcode 16) + mock protocols generated manually or with Mockingbird. Turbine's collectLatest {} test block allows asserting exact emission sequences from StateFlow. Coverage gates: Use Cases ≥ 90%, ViewModels ≥ 80%.
Capture pixel-level screenshots of UI components and diff against committed golden images. Android: Paparazzi library renders Compose UI on the JVM using LayoutLib (same engine as Android Studio Preview) — no emulator required. iOS: iOSSnapshotTestCase renders SwiftUI or UIKit views to UIImage and diffs with stored PNG files. Test matrix: all theme variants (light, dark, high contrast), all supported Dynamic Type sizes (minimum: xSmall, medium, AX3), all localisation variants with different text lengths. Golden images committed to the repository — PRs that change visual appearance fail CI until goldens are intentionally updated.
Test the Repository layer with its dependencies: in-memory Room database for Android, URLProtocol stubbing for network calls (iOS), in-memory SQLite for Core Data/SwiftData. Verify that data flows correctly from data source through mapping to domain model. These tests catch DTO-to-domain mapping bugs that unit tests (which mock the Repository) miss.
Full application on an emulator (Android) or simulator (iOS). Scope to the top 10 critical user journeys only — not every screen. Tools: Espresso (Android) with IdlingResource for async synchronisation; XCUITest (iOS) with accessibility identifier-based element location; Maestro (cross-platform, YAML-based) as an alternative that is more maintainable than programmatic Espresso. Maestro's declarative YAML syntax is readable by QA engineers without Kotlin/Swift knowledge.
Physical device matrix via Firebase Test Lab. 10-20 devices covering top Android OEM/version combinations. iOS: 5 physical device types. Scope: the 5 most critical user journeys (authentication, primary use case, payment if applicable, error recovery, push notification handling). Run on each release candidate, not on every PR.
Consumer-driven contract tests with Pact framework. The mobile application defines the API contract it depends on as a Pact file. CI verifies the BFF satisfies the contract before any backend deployment. Prevents backend changes from breaking the mobile app. Runs in the backend CI pipeline, not the mobile CI pipeline.
All tests use Espresso or XCUITest to drive the full application. Tests are slow (2-5 minutes each), brittle (fail on visual changes unrelated to the tested logic), and provide poor diagnostic information when they fail.
Test business logic through unit tests (milliseconds each, thousands of them). Test visual components through snapshot tests (seconds each). Reserve UI tests for the small set of critical user journeys that require the full stack.
80% code coverage achieved by testing getters, setters, and constructor wiring. No tests for actual business logic.
Coverage targets applied specifically to Use Cases and ViewModels — the layers that contain business logic. A 90% Use Case coverage target means 90% of the lines in Use Case classes are executed by tests. Coverage tooling configured to exclude auto-generated code, data classes without logic, and DI configuration.