Mobile Application Testing Questions

Overview (goal)
I would build a layered, signal-driven test pyramid that balances fast feedback with broad-device reliability: heavy unit tests, focused integration tests on emulators, and curated UI tests on real devices.

Test coverage targets

• Unit: 70–80% logic/code paths (view models, utilities, validators)
• Integration: 15–25% (network layer, DB, platform-API glue)
• UI/E2E: 5–10% (critical user flows: auth, payments, onboarding, camera/location)

Mocking & stubbing

• Use dependency injection to swap real services for mocks in unit tests (Mockito/KMock for Android, Cuckoo/Mockingbird for iOS, or Dart mockito for Flutter).
• For integration tests, use contract-mocks and a local mock server (WireMock, MockWebServer) simulating latency, errors, auth tokens.
• For hardware (camera/GPS), provide platform-level stubs and simulated sensor data.

Device farm strategy

• Emulators/simulators run on every PR for fast feedback.
• Device farm (Firebase Test Lab, AWS Device Farm, BrowserStack) runs nightly and pre-release suites covering: top 30 devices by usage + 3 OS versions per platform, at least one low-end device per major OEM.

Test data management

• Use deterministic seeded test DBs and tokenized test accounts.
• Isolate state per test using fixtures and teardown; use feature flags to enable test-only endpoints.
• Encrypt and rotate sensitive fixtures; store in CI secrets.

Flaky detection & quarantine

• Track flaky tests via CI history (failure rate >5% flagged).
• Auto-quarantine flaky tests to a “flake” pipeline and notify owner; require flaky-fix within SLA (e.g., 2 sprints) or move to manual regression.
• Capture full device logs, screenshots, and video on failure to aid triage.

CI reporting to developers

• Enrich CI with structured reports: per-test pass/fail, stack traces, device model/OS, logs, screenshots, repro steps.
• Post PR comments with unit/integration summary; block merges on failing unit tests, allow flaky-flagged PRs but create a blocking issue.
• Daily dashboard (Grafana) for test health, device coverage, and flaky trends; integrate with Slack for alerts.

Trade-offs & maintenance

• UI tests are slow/expensive—keep them small and high-value. Regularly prune tests and update device matrix based on analytics.
  This strategy gives fast local feedback while ensuring reliability across diverse real devices.

Approach (overview)
Design tests that run deterministically across sizes/orientations by parameterizing device configs, using stable selectors, and isolating external dependencies (network, animations).

Frameworks

• iOS: XCUITest for end-to-end UI flows; SnapshotTesting or iOSSnapshotTestCase for pixel/layout comparisons; use XCTest expectations + XCUI Accessibility Identifiers for stability. Use URLProtocol-based stubs or OHHTTPStubs for network.
• Android: Espresso for interactions + Espresso IdlingResources to wait for async work; androidx.test.uiautomator for cross-app checks; Shot or Paparazzi for screenshot assertions. Use MockWebServer or OkHttp interceptors for network.

Test structure to reduce flakiness

• Use accessibility identifiers / resource IDs (avoid text-based selectors).
• Parameterize tests over device sizes and orientations (JUnit Parameterized / XCTest loops) so same test runs for iPhone SE → iPad and portrait/landscape.
• Centralize setup/teardown and test data; reset app state between tests.
• Synchronize async work with IdlingResources (Android) / expectations (iOS) and disable animations on CI.
• Keep tests small and focused (one assertion per behavior), avoid sleeping; use retries only sparingly.

Mocking network (deterministic tests)

• Inject network layer (protocol/interface) so tests can replace real client with a mock.
• Android example: use MockWebServer to enqueue deterministic JSON responses.

// Kotlin: enqueue a fixed response
val server = MockWebServer()
server.enqueue(MockResponse().setBody(fixtureJson).setResponseCode(200))
val baseUrl = server.url("/").toString()

• iOS example: register a custom URLProtocol that returns fixture data for matching requests.

// Swift: URLProtocol subclass returns local JSON fixture for given request
URLProtocol.registerClass(MockURLProtocol.self)

• Use fixtures/versioned responses, test error and latency scenarios, and run both mocked and a small set of integration tests against a staging server.

This combination ensures reproducible layout and behavior verification across device fragmentation while keeping tests fast and reliable.