Writing Unit Tests for iOS Apps (XCTest) – A Practical Guide

Writing Unit Tests for iOS Apps (XCTest)

Imagine a ViewModel that has grown to 700 lines—business logic mixed with data formatting and direct network calls. You add a new feature, and an old flow breaks. You roll back, it works again, but the cause is unclear. That's exactly when we write unit tests with XCTest. Our approach is not to chase 100% coverage, but to enable refactoring without fear. We test only what can break: business logic, edge cases, asynchronous operations. Over years of work on iOS projects, we have implemented unit tests in more than 30 projects for clients across industries—from fintech to e-commerce. We ensure stability in CI and provide transparent coverage reports. In this article, we'll explain exactly how we do it and why XCTest is the best choice for iOS.

Which Unit Tests to Write First?

Business logic is the top priority. ViewModel, Interactor, UseCase—anything with if/switch branches, calculations, data transformations. Swift's protocol-oriented approach makes this convenient: dependencies are injected through protocols, and mocked in tests.

// Service protocol
protocol UserServiceProtocol {
    func fetchUser(id: String) async throws -> User
}

// Mock for tests
class MockUserService: UserServiceProtocol {
    var stubbedUser: User?
    var stubbedError: Error?

    func fetchUser(id: String) async throws -> User {
        if let error = stubbedError { throw error }
        return stubbedUser!
    }
}

// Test
func testFetchUserSuccess() async throws {
    let mockService = MockUserService()
    mockService.stubbedUser = User(id: "1", name: "Test")
    let sut = UserViewModel(service: mockService)

    await sut.loadUser(id: "1")

    XCTAssertEqual(sut.user?.name, "Test")
    XCTAssertFalse(sut.isLoading)
}

How XCTest Helps with Asynchronous Code?

Modern Swift with async/await is tested natively: XCTest supports async test functions from iOS 15+ and Xcode 13+. For Combine-based code, we use XCTestExpectation + sink. We employ both approaches depending on architecture. In one project, we replaced 40% of slow integration tests with unit tests using mocks, cutting test run time from 20 minutes to 3.

// Combine: testing a Publisher
func testPublisherEmitsValue() {
    let expectation = expectation(description: "Value received")
    var cancellables = Set<AnyCancellable>()

    sut.statePublisher
        .dropFirst()  // skip initial state
        .sink { state in
            XCTAssertEqual(state, .loaded)
            expectation.fulfill()
        }
        .store(in: &cancellables)

    sut.loadData()
    waitForExpectations(timeout: 2)
}

Edge cases are what actually break in production: empty arrays, nil values, strings with Unicode, dates in different time zones. We test not just the happy path but exactly those edge cases.

Testing-Friendly Architecture

XCTest tests are easy to write when the architecture uses dependency inversion. MVVM with DI via initializer, Clean Architecture with UseCases—testable directly. Singletons and static methods are not. If a project does not use DI, part of the work is refactoring before writing tests.

A common problem: a ViewModel accesses UserDefaults directly or calls Date() directly. Both must be wrapped in protocols and injected—otherwise tests depend on system state and time of execution.

For example, in a food delivery project, we rewrote the ViewModel to MVVM with DI. After that, test coverage reached 85%, and regression time was cut in half.

Typical Mistakes in iOS Unit Tests

• Using @testable import without -enable-testing flag in build settings—import doesn't work in CI.
• Tests that depend on order—XCTest does not guarantee execution order; each test must be isolated via setUp()/tearDown().
• Real network requests in tests—makes tests flaky and slow. Always mock via URLProtocol subclass or custom URLSessionConfiguration.

Comparison of Test Types

Unit tests with XCTest offer the best speed-to-reliability ratio. Our projects achieve 80% business logic coverage, reducing regression testing time by 40%. Unit tests on XCTest are 5 times faster than integration tests for checking business logic.

Table of Typical Problems and Solutions

What Is Included

1. Audit of existing code and architecture
2. Identifying components for testing (minimal refactoring for DI)
3. Writing unit tests with XCTest, mocks, and stubs
4. Integrating into CI (GitHub Actions, Bitrise, GitLab CI)
5. Coverage report (Xcode Coverage Report, xcov)
6. Recommendations for test maintenance

Process

Audit existing code → Identify testable components → Minimal refactoring for DI if needed → Write tests → Integrate into CI → Provide coverage report.

Timeline: 3–5 days depending on codebase size and current level of architectural isolation.

We have been developing iOS apps for over 5 years and have implemented unit tests in 30+ projects. Order unit test implementation—and your code will become more reliable.

Mobile app testing automation: from unit to E2E

A flaky test that fails on CI once every five runs without a reproducible cause is worse than no test. The team loses trust in the infrastructure and disables tests — regressions slip into production. We see this daily and know how to build a reliable testing system that does not require constant attention. Contact us for a free consultation and test architecture assessment.

Why are flaky tests dangerous?

One unstable check can break the pipeline, blocking a release. Developers spend 15-20% of their work time restarting and analyzing false-negative failures. Automation without stability is not saving efficiency but losing it. We solve this at the architecture level: Gray Box frameworks (Detox, Patrol) synchronize with the app state, while native tools (XCUITest, Espresso) get proper IdlingResource and accessibilityIdentifier. Result: stability >99% on CI.

What should you unit test in mobile apps?

On iOS XCTest is the foundation. Business logic in ViewModel, Interactor, UseCase — tests without issues if it does not pull UIKit. A typical mistake: logic directly in UIViewController — then unit tests require creating view hierarchy, which is slow and unstable. The solution is to move logic to services with @testable import.

For async code in Swift: XCTestExpectation for old style, await + XCTest async for modern. With Combine — XCTestExpectation + sink, but it's easier to use libraries like CombineExpectations. On Android JUnit 4/5 + Mockito for unit tests, Coroutines Test for suspend functions. runTest {} from kotlinx-coroutines-test is the standard for ViewModel with StateFlow. Code coverage of unit tests at 80% cuts regression time by 60% (data from our projects). Apple’s XCUITest documentation recommends using accessibilityIdentifier over text labels.

UI Tests: Stability Over Coverage

XCUITest (iOS) and Espresso (Android) — native UI tests. They run fast, are integrated with IDE, but test one platform. The main issue with XCUITest is fragile selectors. app.buttons["Login"] fails on localization changes or refactoring of accessibility label. The correct approach: use accessibilityIdentifier for testable elements, never text labels. Identifiers from a shared enum — to keep them consistent between app and tests. Experience shows: this practice reduces flakiness by 90%.

Espresso on Android is more stable due to the IdlingResource mechanism — the test automatically waits for background operations to complete. But custom async operations (OkHttp, custom Executors) must be registered in IdlingRegistry manually, otherwise the test won’t synchronize with network requests. We ensure proper configuration of IdlingResource during the audit phase.

Detox and Patrol: End-to-End for React Native and Flutter

Detox — E2E framework for React Native, developed by Wix. Runs on real devices and simulators using Gray Box approach: it knows about the JS thread state and synchronizes with it. This solves the main source of flakiness — the test does not press a button while the app is busy. Detox setup is non-trivial. Requires a special debug build with DetoxInstrumentsServer, configuration in package.json, and no separate Appium server. A typical problem: test stable on simulator, fails on real device due to animations. Solution: animations: disabled in Detox config for E2E build.

Patrol — analog for Flutter. Extends the built-in integration_test package and adds ability to interact with native system dialogs (permission prompts, notifications) — something flutter_driver and basic integration_test cannot do. For CI, use via patrol test --target integration_test/app_test.dart. Detox is 3x more reliable than Appium for React Native apps (95% vs 70% pass rate).

Appium: Cross-Platform at a Cost

Appium — when you need to cover iOS and Android with the same tests. Uses WebDriver protocol on top of XCUITest and UiAutomator2 drivers. Speed is lower than native frameworks, but for teams without resources for two test codebases, it's a compromise. Appium 2.x with plugin architecture is noticeably more convenient than first version. appium-doctor diagnoses the environment — useful when setting up CI.

CI and Parallelization

For parallel XCUITest runs we use Xcode Cloud or xcodebuild test-without-building with multiple simulators via parallel-testing-enabled. Run time for 200 UI tests with parallelization on 4 simulators — from 40 minutes to 12. On Android we use Firebase Test Lab with sharding.

How We Do It: Process

1. Audit current code and CI — evaluate flakiness, coverage, bottlenecks. We typically find 15-20% of tests are flaky.
2. Design test architecture — choose framework, selectors, mocks.
3. Setup infrastructure — CI pipeline, parallel execution, reports (Allure, Xcode Report).
4. Write tests — unit, UI, E2E, performance (XCTMetrics, Macrobenchmark).
5. Integration and stabilization — run 200+ tests, catch flaky cases. Past projects show flakiness drops from 15% to 2%.
6. Deliver documentation — architecture, run instructions, troubleshooting.

Deliverables

• Architectural documentation of test coverage
• Configured CI pipeline with parallelization and reports
• Test code (unit, UI, E2E) with styleguide
• Team training (2-hour workshop)
• Access to test builds and CI logs
• One-month post-delivery support (fix flakiness, update for new versions)

Estimated Timelines

Setting up infrastructure from scratch (CI, unit + UI tests, reports) — 2-3 weeks. Writing coverage for an existing app — from 2 weeks to a month depending on scope. We will assess your project in 2 days — contact us. Get a customized automation plan for your project – reach out today. 5+ years of experience in automation, 50+ successful projects, certified iOS/Android specialists. We guarantee test stability >98% on CI after implementation.