Integration, Data, and Network Testing

Introduction

An iOS application rarely operates in isolation. It exchanges data with web services, stores information locally, authenticates users, schedules notifications, and often depends on third-party SDKs. Testing these integrations is therefore different from testing a pure function or a single screen. The tester must examine not only whether a component works independently, but also whether components collaborate correctly under normal, delayed, incomplete, duplicated, unauthorized, and failed conditions.

Integration testing provides evidence about these collaborations. In iOS development, the most valuable integration tests are usually controlled tests: they use test servers, mock transports, fakes, stubs, seeded databases, and deterministic fixtures rather than unpredictable production services. Controlled testing makes failures reproducible and allows the team to test cases that are difficult or unsafe to create in a live environment.

This chapter focuses on API communication, persistence, authentication, notifications, third-party SDKs, offline behavior, failure recovery, and sandbox services. The emphasis is practical: a certificate-level developer should be able to design a test boundary, select an appropriate test double, create useful fixtures, and interpret failures responsibly.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish unit, integration, contract, end-to-end, and sandbox testing;
• test URLSession-based APIs with controlled responses and failures;
• verify decoding, validation, retries, cancellation, and error presentation;
• test persistence, migrations, cache rules, and data isolation;
• design authentication tests without exposing real credentials or tokens;
• test notification permission, scheduling, delivery, and deep links;
• isolate third-party SDKs behind application-owned interfaces;
• verify offline behavior and recovery after connectivity returns;
• construct deterministic fixtures and use them to test realistic scenarios;
• identify ethical, security, privacy, and governance responsibilities in integration testing.

1. The Integration-Test Boundary

A unit test examines a small unit, commonly a function or type, with its collaborators replaced by controlled substitutes. An integration test examines the interaction between two or more real components. For example, a repository test might use a real JSON decoder and a real persistence store while replacing only the network transport. An end-to-end test may use the compiled application, a real test server, a database, and a simulated user journey.

These categories are complementary rather than competing:

A useful boundary is the seam: a point at which a dependency can be replaced without changing the behavior being tested. Protocols, injected closures, configurable URLSession instances, and application-owned SDK wrappers are common seams.

For example, instead of allowing a view model to construct URLSession directly, an application can depend on a protocol:

protocol UserService {
    func fetchUser() async throws -> User
}

struct UserViewModel {
    let service: UserService
    var user: User?
}

Production code receives a live implementation. Tests receive a fake implementation that returns a fixture or a selected error. This design improves testability without making the production architecture artificial.

2. APIs and Network Behavior

2.1 What must be tested

An API test should examine more than the HTTP status code. Important dimensions include:

• request method, URL, query parameters, headers, and body;
• authentication and content negotiation headers;
• successful decoding of valid responses;
• handling of missing, additional, or incorrectly typed fields;
• status-code mapping, such as unauthorized, not found, conflict, and server error;
• timeouts, cancellation, connection loss, and malformed data;
• pagination, ordering, duplicate records, and empty collections;
• retry behavior and protection against repeated unsafe operations.

A successful response is not necessarily a successful application operation. The response may decode correctly but violate business rules, contain stale data, or omit a required identifier. Integration tests should therefore verify the transition from transport response to domain result.

2.2 Controlled transports and fixtures

A test double for networking may be a stubbed service, a custom URL protocol, a local test server, or a recorded response fixture. A stubbed service is simple and fast, but it may not prove that requests are correctly formed. A URLProtocol-based approach can inspect the request and return a controlled HTTP response, making it useful for testing URLSession clients.

A fixture is a deliberately selected input representing a meaningful condition. Useful fixtures include:

• a complete valid response;
• an empty response;
• a response containing optional fields as null;
• an older schema version;
• malformed JSON;
• unauthorized and expired-session responses;
• a large collection;
• a response with duplicated or conflicting records.

Fixtures should be versioned with the test code, named by behavior rather than by arbitrary numbers, and kept small enough to understand. Sensitive production data should never be copied into a fixture without explicit authorization, minimization, and anonymization.

2.3 Testing asynchronous behavior

Asynchronous tests must wait for observable completion rather than relying on arbitrary delays. In Swift concurrency, an async test can await an operation directly. The test should also verify cancellation and ensure that a task does not update a deallocated or no-longer-relevant screen.

A basic test structure is:

func testFetchUserDecodesFixture() async throws {
    let transport = StubTransport(response: .userFixture)
    let client = APIClient(transport: transport)

    let user = try await client.fetchUser(id: "u-1")

    XCTAssertEqual(user.id, "u-1")
    XCTAssertEqual(transport.requests.first?.httpMethod, "GET")
}

The important principle is that the test checks both outcome and interaction. A test that checks only the returned user might pass even if the client sends an incorrect method or endpoint.

2.4 Errors, retries, and idempotency

A network layer should translate low-level failures into meaningful application errors. Tests should verify that a timeout is not presented as “invalid password,” and that an expired token leads to reauthentication rather than an infinite retry loop.

Retries require particular care. Retrying a read request may be safe when the service and operation are designed for it. Retrying a state-changing request can create duplicate effects unless the API supports idempotency keys or equivalent safeguards. Tests should count attempts and verify the stopping condition.

For example, a retry policy might allow two retries after transient failures, producing at most three attempts. This is a policy statement, not a universal rule; the correct number depends on the operation, user experience, service limits, and failure type. Tests should cover zero retries, successful retry, exhausted retries, cancellation during retry, and non-retryable errors.

3. Persistence and Data Integrity

Local persistence may use UserDefaults, files, Core Data, SwiftData, SQLite, or a specialized cache. Tests should establish whether the component is being tested as a data structure, a persistence mechanism, or part of a repository workflow.

3.1 Isolation and lifecycle

Each test should receive a clean store or a controlled fixture. A shared persistent store can cause order-dependent tests: one test leaves data that changes another test’s result. Temporary directories, in-memory stores, unique database names, and explicit teardown are common solutions.

Persistence tests should examine:

• insertion, retrieval, update, and deletion;
• uniqueness constraints and duplicate handling;
• sorting and filtering;
• relationships and deletion rules;
• optional and missing values;
• migration from an earlier schema;
• behavior when storage is unavailable or full;
• consistency between cached data and server data.

A repository test might verify that a successful API response is saved and can later be read offline. It should also verify what happens if saving fails after the network request succeeds. The application must have an intentional policy: display the fresh result without caching it, report a recoverable warning, or retry persistence.

3.2 Migrations and compatibility

A schema migration changes the representation of stored data while preserving its intended meaning. Tests should create data using the old schema, perform the migration, and verify both data preservation and new defaults. They should include empty stores, partially populated stores, and records containing values that no longer satisfy new constraints.

Migration tests are especially important because a developer’s device may contain clean data while a customer’s device contains years of historical records. A migration that works only on a new installation is incomplete.

4. Authentication and Authorization Testing

Authentication establishes identity; authorization determines what that identity may do. Tests must keep these concerns separate. A valid login does not imply permission to access every resource.

A safe authentication test suite may include:

• valid credentials in a test environment;
• invalid credentials and account lockout rules;
• expired access tokens;
• refresh-token success and failure;
• logout and token deletion;
• revoked sessions;
• insufficient permissions;
• clock differences affecting token validity;
• concurrent requests encountering the same expired token.

Never commit real credentials, private keys, production tokens, or personally identifiable information to source control. Test accounts should be limited, monitored, and disposable. Secrets should be supplied through secure CI configuration or a secrets manager, not embedded in the application binary or fixture repository.

Authentication tests should verify storage behavior as well as network behavior. After logout, access and refresh tokens should be removed according to the security design. A test should confirm that a protected request cannot silently reuse credentials after logout.

When an access token expires, multiple requests may discover expiration simultaneously. A robust client coordinates refresh operations so that it does not launch an uncontrolled number of refresh requests. Tests should simulate concurrent failures and verify that requests either receive a refreshed token or fail consistently when refresh is rejected.

5. Notifications and Deep Links

Notifications involve several systems: application scheduling, user permission, operating-system delivery, provider services, payload interpretation, and navigation. Testing should separate these layers.

Local-notification tests can verify that the correct request is scheduled, including title, body, trigger, identifier, and user-info payload. They should also verify replacement and cancellation behavior. Remote notification tests commonly use a provider sandbox or a simulated payload. The application should be tested with foreground, background, terminated, malformed, and unexpected notification states.

A notification payload should be treated as untrusted input. Tests should ensure that missing or invalid deep-link data does not crash the application or navigate to an unauthorized resource. A deep link should be validated against the current authentication state and permitted destination.

Permission behavior must be tested as a state machine: not determined, granted, denied, and restricted. Tests should not assume that permission can be reset repeatedly on a physical device. Where possible, use simulator settings, dependency wrappers, and UI tests for the permission-dependent path.

6. Third-Party SDKs and Sandbox Services

Analytics, payment, maps, identity, messaging, and crash-reporting SDKs can introduce network calls, global state, device requirements, and licensing constraints. The safest design places an application-owned interface between the app and the SDK:

protocol AnalyticsReporting {
    func record(event: AnalyticsEvent)
}

Production code uses the SDK adapter. Tests use a spy that records events without contacting the provider. The spy can verify event names, required properties, and the absence of sensitive values.

A sandbox service is valuable when behavior depends on provider-side rules, such as payment authorization or push delivery. Sandbox tests should be scheduled separately from fast unit and integration suites because they may require network access, special accounts, rate limits, or manual setup. They are evidence about provider integration, not a replacement for deterministic local tests.

Test doubles have different purposes:

Overusing strict mocks can make tests fragile. Prefer verifying meaningful contracts and outcomes rather than every internal call.

7. Offline-First Behavior and Recovery

Connectivity is not binary from the user’s perspective. A device may have no connection, high latency, intermittent access, captive-portal interference, or a connection that reaches the internet but not the required service.

An offline-capable design should define:

• which features remain available;
• whether cached data is read-only or editable;
• how stale data is labelled;
• how writes are queued;
• how conflicts are resolved;
• what happens when queued work fails;
• how the user is informed without being interrupted unnecessarily.

Tests should simulate transitions rather than only static offline mode: online → offline, offline → online, request interrupted midway, and application termination with pending work. Recovery must be idempotent where possible. If a queued operation is submitted twice, the server or client must prevent unintended duplication.

A useful fixture set includes a cached object, a newer server object, a local edit, and a conflict response. The expected resolution policy should be explicit—for example, server-wins, client-wins, field-level merge, or user choice. There is no universally correct policy; correctness depends on the domain and the cost of losing either version.

8. A Practical Integration-Test Workflow

A disciplined workflow reduces false failures:

1. Identify the boundary and the behavior under test.
2. Define success, failure, cancellation, and recovery outcomes.
3. Select real components and replace only uncontrolled dependencies.
4. Create minimal, representative fixtures.
5. Assert request formation, returned data, side effects, and user-visible state.
6. Reset stores, clocks, permissions, and test doubles between tests.
7. Run deterministic tests in every build and sandbox tests in a controlled stage.
8. Record failures with request identifiers, fixture names, environment, and logs that exclude secrets.

Time, randomness, and connectivity are hidden sources of nondeterminism. Inject a clock where token expiry or scheduling is tested. Inject randomness where identifiers or backoff decisions matter. Use a controllable network rather than waiting for real network conditions.

Illustrative Case: TrailKeeper Offline Sync

Background

TrailKeeper is an illustrative hiking application. It downloads trail information, allows users to save notes, and sends reminders before a planned hike. The application uses a REST API, local persistence, authentication, and a notification service.

Problem

During field testing, users reported that notes disappeared after connectivity returned. Some users also received duplicate reminders. The original tests covered successful online downloads but did not cover interrupted writes, duplicate synchronization, or notification replacement.

Analysis

The team mapped the workflow into four boundaries: API transport, repository and local store, synchronization queue, and notification scheduler. They identified two likely causes: a queued note was removed before the server acknowledged it, and reminders were scheduled with random identifiers, preventing replacement.

Approach

The team created deterministic fixtures for successful acknowledgement, timeout, conflict, and duplicate submission. A fake clock controlled reminder times. A fake transport recorded request identifiers and could fail on a selected attempt. The persistence test used a temporary store for every test. The notification adapter used a spy to verify that the same logical reminder identifier was reused.

Tests then verified that a note remained queued after a timeout, was removed only after acknowledgement, and was not applied twice when the acknowledgement was delayed. Conflict behavior was specified as user-visible resolution rather than silent overwrite. Notification tests verified scheduling, replacement, cancellation, and deep-link validation.

Outcome

The revised design made queue state explicit and used stable operation identifiers. The test suite reproduced the original defect without network access and prevented its recurrence. Sandbox testing later confirmed that provider delivery worked, while local tests remained responsible for deterministic application behavior.

Learning Points

The central lesson is that integration testing is not simply “calling the real service.” It is the deliberate examination of boundaries, state transitions, side effects, and recovery policies. Controlled doubles made rare failures reproducible; sandbox testing provided additional confidence about provider behavior.

Challenges, Ethics, and Governance

Integration tests can expose personal data, credentials, device identifiers, location information, and behavioral records. Teams should apply data minimization, least privilege, retention limits, access control, and secure deletion. Logs should redact authorization headers, tokens, payment details, and unnecessary user content.

Tests involving payments, health information, location, or children’s data may be subject to contractual, organizational, or legal requirements. A sandbox does not automatically make every data practice acceptable. Test data must be governed throughout its lifecycle.

Artificial intelligence can assist with generating fixture variations, identifying untested status codes, or summarizing logs, but generated tests require human review. AI tools should not receive secrets or identifiable production data. A generated test that asserts an implementation detail without verifying meaningful behavior can increase maintenance cost rather than quality.

Best Practices

• Design explicit seams for network, storage, time, notifications, and SDKs.
• Prefer deterministic fixtures over live production data.
• Test both happy paths and state transitions into failure and recovery.
• Verify requests, responses, side effects, and user-visible outcomes.
• Isolate persistent stores and reset global state between tests.
• Treat notification payloads and server data as untrusted input.
• Keep credentials and tokens outside source control and test logs.
• Use sandbox services for provider-specific confidence, not as the only test layer.
• Make retry, caching, synchronization, and conflict policies explicit.
• Keep fast integration tests in continuous integration and schedule slower external tests deliberately.

Chapter Summary

Integration testing evaluates collaboration between application components and external systems. Effective iOS testing uses seams, dependency injection, controlled transports, fakes, spies, mocks, fixtures, temporary stores, and sandbox services. API tests must cover request formation, decoding, status errors, cancellation, retries, and malformed data. Persistence tests must address isolation, integrity, migration, and cache policy. Authentication testing separates identity from authorization and protects secrets. Notification testing examines permission, scheduling, delivery, payload validation, and deep links. Third-party SDKs should be wrapped behind application-owned interfaces. Offline testing must model interruption, queued work, conflicts, and recovery. Ethical testing requires privacy protection, least privilege, secure logging, and responsible use of test data.

Key Terms

Integration test: A test of collaboration between two or more components.

Fixture: Controlled input representing a meaningful test condition.

Test double: A substitute used to control or observe a dependency.

Stub: A double that returns predetermined responses.

Fake: A simplified working implementation.

Spy: A double that records interactions.

Mock: A double that verifies expected interactions.

Seam: A replaceable boundary in a design.

Contract test: A test that checks agreement between communicating systems.

Sandbox: A provider-controlled environment separated from production.

Persistence: The storage of data beyond the immediate execution of code.

Migration: A controlled change from one data schema to another.

Authentication: Verification of an identity.

Authorization: Determination of permitted actions.

Idempotency: A property allowing repeated execution without unintended additional effect.

Deep link: A link that directs an application to a specific destination.

Offline-first: A design that remains useful when network access is absent or unreliable.

Conflict resolution: A policy for reconciling differing local and remote data.

Review Questions

Short Answer Questions

1. What is the principal difference between an integration test and a unit test?
2. Why should production data generally not be used directly as a test fixture?
3. What is the purpose of an application-owned wrapper around a third-party SDK?
4. Why must authentication and authorization be tested separately?
5. Name two conditions that should be tested in an offline-capable application.

Long Answer Questions

1. Explain how a URLSession-based API client can be tested with a controlled transport. Identify the request and response properties that should be asserted.
2. Describe a persistence test strategy that prevents tests from interfering with one another and includes migration coverage.
3. Explain how token expiry, refresh, logout, and concurrent requests should be tested.
4. Discuss the roles of stubs, fakes, spies, mocks, and sandbox services in an integration-test program.
5. Design a notification testing strategy covering permission states, scheduling, delivery, malformed payloads, and deep links.

Analytical / Application Questions

1. An app retries a failed purchase request three times and sometimes creates duplicate purchases. Analyze the likely design problem and propose a safer testing and implementation approach.
2. A note is visible offline but disappears after synchronization fails. Specify fixtures, test doubles, assertions, and recovery behavior needed to diagnose and prevent the defect.
3. A team reports that its sandbox tests pass, but users still experience crashes when receiving malformed notification payloads. Explain why the test coverage is insufficient and design additional controlled tests.

Multiple Choice Questions with Answers

Question 1

Which test double primarily records interactions for later verification?

A. Stub

B. Spy

C. Fake

D. Simulator

Correct Answer: B. Spy

Question 2

Why should a persistent store normally be isolated for each test?

A. To increase network speed

B. To avoid order-dependent results

C. To bypass schema validation

D. To guarantee production data is used

Correct Answer: B. To avoid order-dependent results

Question 3

Which operation generally requires special care before automatic retry because it may create duplicate effects?

A. Reading a cached profile

B. Downloading a public image

C. Submitting a state-changing purchase

D. Parsing a local JSON file

Correct Answer: C. Submitting a state-changing purchase

Question 4

What is the main purpose of an application-owned interface around a third-party SDK?

A. To make the SDK production-only

B. To remove the need for provider documentation

C. To create a replaceable and testable boundary

D. To guarantee network availability

Correct Answer: C. To create a replaceable and testable boundary

Question 5

Which statement correctly distinguishes authentication from authorization?

A. Authentication verifies identity; authorization determines permitted actions

B. Authentication determines permissions; authorization encrypts passwords

C. Authentication applies only offline; authorization applies only online

D. They are two names for the same operation

Correct Answer: A. Authentication verifies identity; authorization determines permitted actions

Question 6

What should happen to a queued offline write after a transient failure?

A. It should always be deleted immediately

B. It should remain available for a defined recovery policy

C. It should be silently duplicated

D. It should be converted into a notification

Correct Answer: B. It should remain available for a defined recovery policy

Question 7

Which fixture is most appropriate for testing robust API decoding?

A. Only the largest production database

B. A valid response and responses with missing or malformed fields

C. A random response generated during each test

D. A response containing real user tokens

Correct Answer: B. A valid response and responses with missing or malformed fields

Question 8

Why should notification payloads be treated as untrusted input?

A. They can contain invalid or unexpected values

B. They are always encrypted incorrectly

C. They cannot contain navigation data

D. They are never delivered by an operating system

Correct Answer: A. They can contain invalid or unexpected values

Question 9

What is a sandbox service primarily intended to provide?

A. A replacement for all local tests

B. Provider-specific testing without using production

C. Unlimited production credentials

D. A guarantee that every device is offline

Correct Answer: B. Provider-specific testing without using production

Question 10

Which practice best protects authentication secrets in integration testing?

A. Commit them to the repository for convenience

B. Print them in failure logs

C. Supply them through secure configuration and redact logs

D. Place them in notification payloads

Correct Answer: C. Supply them through secure configuration and redact logs