Testing in Mobile Development: What It Is, Types and How to Organize

Testing Levels: Unit, Integration, E2E

Unit Testing

Unit tests are the foundation of mobile app testing. They verify the smallest unit of code — a single function, method or class in isolation from the rest of the system. In mobile development, unit tests are written in JUnit (Android) and XCTest (iOS). A good unit test must be fast, independent, and repeatable — it should not depend on the network, database or UI components. Test doubles are used for isolation: mocks, stubs and fakes.

Mockito (Java/Kotlin) and MockK (Kotlin-first) are popular libraries for creating mock objects on Android. On iOS, OCMock, Cuckoo or manual protocols are used for mocking. Rule: unit tests should cover business logic and data models. UI tests should not duplicate unit tests — they verify user interaction with the interface.

Integration Testing

Integration tests verify interaction between components: repository with database, ViewModel with API service, navigation between screens. Unlike unit tests, integration tests use real or near-real dependencies (e.g., in-memory database or mock server). Robolectric is a framework for running Android tests on JVM without an emulator, speeding up integration tests by 10x.

Snapshot tests (Golden Tests) are a special type of integration test that compare a rendered UI component against a reference image (snapshot). If the appearance changes, the test fails — the developer sees what changed. Facebook SnapshotTestCase (iOS) and Shot (Android) are popular tools for snapshot testing.

E2E and UI Testing

E2E tests (end-to-end) verify the full user scenario from start to finish: app launch, login, performing an action, checking the result. UI tests are a subset of E2E focused on the interface. Tools: Espresso (Android), XCUITest (iOS), Detox (React Native). E2E tests are the slowest, so they are run separately on CI — typically on nightly builds.

iOS Tools: XCTest and XCUITest

XCTest

XCTest is Apple's built-in framework for unit testing mobile applications. XCTestRunner runs tests on the simulator or a real device. Tests inherit from XCTestCase, contain setUp and tearDown for preparation and cleanup. XCTest includes XCTAssert for assertions (XCTAssertEqual, XCTAssertNil, XCTAssertTrue) and XCTWaiter for waiting for asynchronous operations.

Example of a simple XCTest test: creating a User model, checking the correctness of initialization, name formatting and age calculation. Code Coverage in Xcode shows which lines of code are covered by tests — the goal for commercial projects: at least 70–80% coverage of business logic. XCTest is integrated with Xcode Server and CI systems via xcodebuild test.

XCUITest

XCUITest is Apple's framework for UI testing. It works through accessibility identifiers: XCUIElementQuery finds buttons, input fields, tables by label, identifier or type. XCUITest records a sequence of actions (record/playback) and generates test code. Important: all UI elements must have an accessibilityIdentifier for stable test operation.

Android Tools: JUnit, Espresso, Robolectric

JUnit and Mockito

JUnit is the basic framework for unit testing mobile applications on Java/Kotlin. On Android, JUnit 4 (latest stable version 4.13.2) and JUnit 5 for new projects are used. Mockito is a library for creating mock objects: when(mock.method()).thenReturn(value) — a standard pattern for isolating the tested class from dependencies.

Example of a JUnit test for Android:

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mock;
import org.mockito.junit.MockitoJUnitRunner;

import static org.junit.Assert.*;
import static org.mockito.Mockito.*;

@RunWith(MockitoJUnitRunner.class)
public class LoginViewModelTest {

    @Mock
    AuthRepository authRepository;

    @Test
    public void login_emptyEmail_returnsError() {
        LoginViewModel vm = new LoginViewModel(authRepository);
        String result = vm.login("", "password123");
        assertEquals("Email cannot be empty", result);
        verify(authRepository, never()).authenticate(any());
    }
}

Espresso and UI Automator

Espresso is Google's framework for Android UI tests. Espresso automatically synchronizes with the UI thread: onView(withId(R.id.button)).perform(click()).check(matches(isDisplayed())). Espresso is easy to write and stable thanks to built-in idle state waiting. UI Automator is a framework for cross-application tests that can interact with system elements (permission dialogs, notification shade).

Cross-Platform Tools: Detox, Appium

Detox for React Native

Detox is a gray-box E2E framework for testing React Native mobile applications from Wix. Detox works on both platforms from a single test codebase, using Espresso (Android) and XCUITest (iOS) under the hood. Detox automatically waits for the app to become idle (no animations, network requests, timers) and only then performs the next action.

Appium

Appium is a universal cross-platform framework supporting Android, iOS, Web and hybrid applications. Appium uses the WebDriver protocol and supports any programming language (Java, Python, JS, Ruby). Appium Server works as an HTTP server that translates commands into native UI Automator / XCUITest commands. The main disadvantage of Appium is speed: tests run slower than native Espresso or XCUITest.

TDD and BDD: Testing Methodologies

TDD: Test-Driven Development

TDD is a mobile app testing methodology where the test is written before the implementation code. The Red-Green-Refactor cycle: (1) write a test that fails (Red), (2) write minimal code to make the test pass (Green), (3) refactor the code while keeping the test passing. TDD gives 100% test coverage for new functionality and a clean architecture, since the test is the first specification of the requirement.

BDD: Behaviour-Driven Development

BDD is an extension of TDD where tests are written in natural language in Given-When-Then format. Given (context) — When (action) — Then (expected result). BDD tests are understandable to all team members: developers, testers, analysts and clients. Mock vs Stub vs Fake: Mock verifies interaction (was the method called), Stub returns fixed data, Fake is a simplified working implementation (e.g., in-memory DB). At IT Sectr, we use TDD for critical business logic and BDD for acceptance scenarios.

Test Doubles is the general name for objects that replace real dependencies in tests. There are four types: Dummy (object to fill parameters, not used), Stub (returns given values), Spy (records calls for verification), Mock (predefines expected calls). Understanding the difference is critical for proper test design.

CI/CD and Device Farm

Test Automation in CI/CD

CI/CD — Continuous Integration and Continuous Delivery: the practice of automatically building and testing mobile applications with every code change. In mobile development, the CI/CD pipeline includes: linting, unit tests, integration tests, APK/IPA build and UI tests. GitHub Actions and Bitrise are popular platforms for mobile CI/CD. Tests should run fast: unit tests in 1–2 minutes, integration tests in 5–10, UI tests in 15–30 minutes.

Device Farm

Device Farm is a farm of real devices for testing. Firebase Test Lab (Android) and Xcode Cloud (iOS) provide cloud access to hundreds of device models. Device Farm reveals issues not visible on emulators: different screen sizes, performance on older devices, compatibility issues. At IT Sectr, we use Firebase Test Lab for Android and Xcode Cloud for iOS on a regular basis.