Unit and Component Testing

Introduction

Unit and component testing is the disciplined practice of verifying small, understandable parts of an iOS application in isolation or near isolation. In Swift development, these parts commonly include pure functions, model types, view models, networking clients, persistence adapters, parsers, and error-handling paths. Effective tests provide evidence that software behaves as intended before it is integrated into a complete user interface or released to users.

Testing is not limited to checking whether an application launches. A reliable test suite examines normal behaviour, invalid input, boundary conditions, state transitions, failures, and asynchronous operations. It also helps developers change code safely. When a test fails, the failure should identify a meaningful defect rather than reflect timing, shared state, network availability, or an overly fragile implementation assumption.

This chapter uses Swift and XCTest examples. The principles also apply to Swift Testing and other testing frameworks. The central idea is that tests should be fast, deterministic, focused, readable, and valuable to the development team.

Learning Objectives

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

• distinguish unit, component, integration, and user-interface tests;
• design tests for Swift logic, models, and view models;
• test valid input, invalid input, boundaries, and error paths;
• verify state transitions without coupling tests to implementation details;
• test asynchronous code reliably;
• use dependency injection and test doubles effectively;
• recognise common test smells and sources of flaky tests; and
• interpret test results and improve test-suite maintainability.

1. The Role of Unit and Component Tests

A unit is the smallest meaningful testable behaviour in a system. It may be a function, a method, a type, or a closely related group of operations. The unit should be tested independently from unrelated concerns. For example, a function that calculates a shopping-cart total can be tested without creating a view controller, contacting a server, or writing to a database.

A component is a larger cohesive part of an application, such as a view model together with a repository protocol and a fake repository. Component tests verify collaboration and observable behaviour while still replacing external systems such as real servers, payment services, or production databases.

Unit and component tests do not replace other test levels. Instead, they provide a broad, fast foundation. A practical iOS test suite normally contains many unit tests, a useful number of component tests, fewer integration tests, and a small number of carefully selected UI tests.

A good test has three characteristics:

1. Focused: it verifies one behaviour or closely related behaviour.
2. Deterministic: repeated execution produces the same result when the code has not changed.
3. Observable: it checks outcomes that matter to users or other components rather than private implementation details.

A common structure is Arrange–Act–Assert:

• Arrange: construct the subject and its dependencies;
• Act: perform the operation under test; and
• Assert: verify the result, state, or interaction.

For example, a test for a discount function arranges a price and discount, acts by calling the function, and asserts the resulting amount. The test should not need to know whether the implementation uses a loop, a helper method, or a particular private variable.

2. Designing Code for Testability

Testability is strongly influenced by design. Code that performs calculation, networking, persistence, and UI updates in one method is difficult to test. Code with clear responsibilities and explicit dependencies is easier to test.

Pure functions

A pure function returns the same output for the same input and has no observable side effects. For example:

func taxAmount(for price: Decimal, rate: Decimal) -> Decimal {
    price * rate
}

This function is straightforward to test because it does not depend on time, networking, device state, or global variables.

Protocol-based dependencies

External services should usually be represented by protocols. Production code can use a real implementation, while tests can use a stub or spy.

protocol RecipeRepository {
    func fetchRecipes() async throws -> [Recipe]
}

struct Recipe {
    let name: String
}

A view model can receive a repository through its initializer:

@MainActor
final class RecipeListViewModel {
    enum State: Equatable {
        case idle
        case loading
        case loaded([String])
        case failed(String)
    }

    private let repository: RecipeRepository
    private(set) var state: State = .idle

    init(repository: RecipeRepository) {
        self.repository = repository
    }

    func load() async {
        state = .loading
        do {
            let recipes = try await repository.fetchRecipes()
            state = .loaded(recipes.map(\.name))
        } catch {
            state = .failed("Unable to load recipes")
        }
    }
}

The view model does not create its own repository. This is dependency injection: a dependency is supplied from outside. It improves substitution, reduces hidden coupling, and makes the test setup explicit.

3. Testing Swift Logic and Models

Logic tests should include representative normal cases and meaningful exceptional cases. For a function that validates a password, useful categories may include a valid password, an empty string, a value at the minimum length, and a value just below the minimum length.

Consider a model with a validation rule:

struct UsernameValidator {
    static func isValid(_ username: String) -> Bool {
        let count = username.trimmingCharacters(in: .whitespacesAndNewlines).count
        return (3...20).contains(count)
    }
}

Tests should make the boundary explicit:

import XCTest
@testable import RecipeApp

final class UsernameValidatorTests: XCTestCase {
    func testUsernameWithThreeCharactersIsValid() {
        XCTAssertTrue(UsernameValidator.isValid("Amy"))
    }

    func testUsernameWithTwoCharactersIsInvalid() {
        XCTAssertFalse(UsernameValidator.isValid("Al"))
    }

    func testWhitespaceOnlyUsernameIsInvalid() {
        XCTAssertFalse(UsernameValidator.isValid("   "))
    }
}

The tests communicate the rule more clearly than a single broad test. Test names should describe behaviour, not implementation. testUsernameWithTwoCharactersIsInvalid remains useful if the validation algorithm changes.

Models and equality

Models should expose meaningful equality when equality is part of their domain meaning. Swift’s Equatable conformance can simplify assertions:

struct Product: Equatable {
    let id: Int
    let name: String
    let price: Decimal
}

When testing floating-point calculations, direct equality may be inappropriate because binary floating-point representation can produce small differences. Prefer a tolerance when the domain permits it, and state the tolerance explicitly. For currency, Decimal or integer minor units such as cents are often safer than Double, although the correct choice depends on the application and its financial requirements.

Collections and ordering

A test should assert ordering only when ordering is part of the contract. If an API promises alphabetical order, assert the order. If it promises only a set of results, compare contents without imposing an accidental sequence requirement. Overly strict assertions create fragile tests.

4. Boundaries and Negative Testing

A boundary is a value at, just inside, or just outside a rule. Boundary testing is valuable because defects frequently occur at transitions between valid and invalid regions.

For a rule that accepts ages from 18 through 65 inclusive, the important values are:

The phrase “through 65 inclusive” matters. The implementation should use an inclusive range if that is the intended contract. Tests should verify the contract rather than merely repeat the implementation.

Negative testing examines invalid input and failure conditions. Examples include malformed JSON, missing required fields, an unavailable repository, an expired authentication token, an empty search query, and an attempt to move from a completed state back to loading when that transition is forbidden.

A useful test matrix asks:

• What is the smallest valid input?
• What is the largest valid input?
• What is just outside each boundary?
• What happens with an empty value?
• What happens with malformed or unexpected data?
• What happens when a dependency fails?
• Is the error visible, recoverable, and safe?

5. Error Handling and Failure Semantics

Error tests should verify both that an error occurs and that the application responds appropriately. Merely asserting that a method throws may be insufficient. A view model may also need to show an error state, avoid displaying stale data, or permit retry.

Swift supports typed errors:

enum LoginError: Error, Equatable {
    case invalidCredentials
    case serviceUnavailable
}

An XCTest assertion can verify the specific error:

func testLoginReportsInvalidCredentials() async {
    let service = StubLoginService(result: .failure(.invalidCredentials))
    let viewModel = LoginViewModel(service: service)

    await viewModel.login(username: "user", password: "wrong")

    XCTAssertEqual(viewModel.state, .failed("Incorrect username or password"))
}

Error messages should not expose passwords, tokens, personal information, or server internals. Tests can therefore support security and privacy by checking that user-facing errors are safe and that sensitive values are not included.

Tests should also distinguish expected domain errors from programming defects. An invalid form submission may be a normal recoverable condition. An impossible state caused by violated invariants may indicate a defect that should not be silently converted into a generic message.

6. Testing View Models and State Transitions

View models often transform domain data into presentation state. Their tests should focus on observable state and meaningful interactions. A state machine is a useful mental model:

idle → loading → loaded
             ↘ failed → loading (retry)

The arrows represent permitted transitions. A test should verify important transitions, not every private assignment.

For the RecipeListViewModel, a successful test might be:

struct StubRecipeRepository: RecipeRepository {
    let result: Result<[Recipe], Error>

    func fetchRecipes() async throws -> [Recipe] {
        try result.get()
    }
}

final class RecipeListViewModelTests: XCTestCase {
    func testLoadMovesToLoadedStateWithRecipeNames() async {
        let repository = StubRecipeRepository(
            result: .success([Recipe(name: "Soup")])
        )
        let viewModel = await RecipeListViewModel(repository: repository)

        await viewModel.load()

        let state = await viewModel.state
        XCTAssertEqual(state, .loaded(["Soup"]))
    }
}

Because the view model is annotated @MainActor, test access may also need to occur on the main actor depending on the Swift version and XCTest configuration. The important principle is actor correctness: tests should not bypass concurrency rules merely to make assertions compile.

A state-transition test for failure should verify that a repository error becomes a safe user-facing state. A retry test should verify that a failed view model can return to loading and eventually loaded when the dependency succeeds.

Avoid asserting every intermediate state unless it is observable and required. For example, a test that depends on a precise number of private callbacks is likely coupled to implementation detail. If loading status is part of the user experience, it is appropriate to test it; otherwise, testing only the final state may be more robust.

7. Asynchronous Testing

Asynchronous code introduces time, scheduling, cancellation, and ordering concerns. Modern Swift tests should generally use async test methods rather than arbitrary sleeps.

func testFetchReturnsExpectedRecipes() async throws {
    let repository = StubRecipeRepository(
        result: .success([Recipe(name: "Salad")])
    )

    let recipes = try await repository.fetchRecipes()

    XCTAssertEqual(recipes.map(\.name), ["Salad"])
}

Why sleeps are a test smell

A test such as try await Task.sleep(for: .milliseconds(100)) does not prove that an operation has completed. It merely waits for a guessed duration. On a fast machine the delay is wasteful; on a busy machine it may be insufficient. This produces slow or flaky tests.

Better approaches include:

• awaiting the operation directly;
• using an async continuation or controlled clock where appropriate;
• injecting a scheduler or clock;
• using an expectation for callback-based APIs; and
• providing a deterministic test double that signals completion.

For legacy completion-handler APIs, XCTest expectations remain useful:

func testCompletionHandlerReturnsValue() {
    let expectation = expectation(description: "Completion called")
    let client = StubClient()

    client.fetch { result in
        XCTAssertEqual(try? result.get(), "OK")
        expectation.fulfill()
    }

    wait(for: [expectation], timeout: 1.0)
}

The timeout is a safety limit, not the mechanism that makes the test pass. The completion handler must explicitly fulfil the expectation. Tests should also detect multiple fulfilments when that would indicate a defect.

Cancellation

Cancellation should be tested when it is part of the contract. A task that is cancelled should not update the UI with stale results or continue expensive work unnecessarily. A controllable stub can pause until the test releases it, allowing the test to verify cancellation without depending on real network timing.

Main-actor and UI isolation

UI-related state often belongs to the main actor. Tests must respect actor isolation and should avoid racing background work against assertions. Await the operation that causes the state change, then inspect the state on the correct actor.

8. Test Doubles

A test double is a replacement for a real dependency. Common types include:

• Stub: returns predetermined data;
• Spy: records calls or arguments for later inspection;
• Mock: verifies expected interactions, often with strict rules;
• Fake: provides a lightweight working implementation; and
• Dummy: exists only to satisfy a parameter and is not used.

For example, a spy can verify that a save operation occurred:

final class SaveSpy: RecipeSaving {
    private(set) var saved: [Recipe] = []

    func save(_ recipe: Recipe) {
        saved.append(recipe)
    }
}

Use the simplest double that answers the testing question. Excessive mocking can make tests reflect the call sequence rather than the required behaviour. If a test fails because a private method was renamed even though the user-visible result is unchanged, it may be too coupled to implementation.

9. Test Smells and Flaky Tests

A test smell is a pattern suggesting that a test or test suite is difficult to understand, maintain, or trust. A flaky test passes and fails unpredictably without a relevant product-code change.

Common sources of flakiness include real time, random values, thread scheduling, shared files, global singletons, network access, locale, time zone, and test order. A test that depends on the current date should inject a clock or use a fixed date. A test that depends on the current locale should set the locale explicitly or avoid locale-sensitive assumptions.

Flaky tests reduce confidence. Developers may rerun them until they pass, ignore failures, or disable them. This is dangerous because a test suite that cannot be trusted cannot provide effective regression protection.

When diagnosing a flaky test:

1. reproduce it repeatedly, preferably in isolation and in the full suite;
2. record environmental conditions and failure output;
3. remove timing guesses and shared state;
4. control randomness, clocks, locale, and dependencies;
5. inspect concurrency and cancellation; and
6. fix the underlying cause rather than increasing a timeout blindly.

10. A Detailed Applied Case: Testing a Recipe Search Feature

Background

Consider an illustrative recipe application. A search screen accepts a query, requests matching recipes from a repository, and displays loading, results, empty, or error states. The repository may use a remote HTTP service in production.

Problem

An initial implementation creates the networking client inside the view model. Tests must therefore contact a server. They sometimes fail because the network is unavailable, the server is slow, or the returned data changes. The view model also treats an empty result as an error, confusing users.

Analysis

The feature contains several independent behaviours:

• blank queries should be rejected or ignored according to the product rule;
• a valid query should enter loading state;
• successful results should become display models;
• an empty successful response should produce an empty state;
• repository failure should produce a safe error state; and
• a retry should attempt the request again.

These behaviours can be tested without the network by injecting a repository protocol.

Approach and solution

A stub repository returns a controlled result. Separate tests cover each meaningful path. A spy can record the query and number of calls. The test does not inspect private networking code; it checks state and required interactions.

For example, a blank-query test might assert that the repository was not called. A success test supplies two recipes and checks that two presentation names appear. An error test supplies a typed repository failure and checks the safe error state. A retry test configures the spy to fail first and succeed second, then verifies two calls and a loaded final state.

The tests should use fixed values, not server data or current time. If the view model is main-actor isolated, the tests should await its methods and read state on the appropriate actor.

Outcome

The resulting tests run quickly and consistently on a developer machine and in continuous integration. They detect changes to validation, mapping, error handling, and retry behaviour. Integration tests can separately verify the real HTTP adapter, while component tests remain independent of server availability.

Learning points

The case demonstrates that testability is a design property. Dependency injection separates policy from mechanism, controlled doubles remove environmental uncertainty, and state-focused assertions protect user-visible behaviour. It also demonstrates that “more realistic” tests are not always better: a unit test using a real network is less deterministic and less diagnostic than a focused test using a stub.

11. Coverage, Quality, and Professional Practice

Code coverage reports the proportion of instrumented code executed by tests, but coverage is not the same as correctness. A test can execute a line without checking its result. High coverage with weak assertions may provide false confidence, while valuable tests may exercise complex behaviours represented by relatively few lines.

Use coverage as a prompt for investigation, not as the sole quality target. Prioritise business-critical logic, security-sensitive decisions, error handling, boundary conditions, and code with a history of defects.

Tests should be reviewed like production code. They need clear names, appropriate abstraction, small fixtures, and meaningful failure messages. Continuous integration should run unit and component tests on every relevant change. Failures should block delivery when they indicate a real regression, but teams should also maintain a process for quarantining and repairing genuinely flaky tests rather than silently ignoring them.

Testing has ethical implications. Tests should not embed real personal data, production credentials, or private health and financial information. Test fixtures should be synthetic or appropriately anonymised. Logs and failure messages should avoid exposing secrets. Automated tests should also consider accessibility-related behaviour where it is part of the component contract, such as meaningful labels or correct enabled and disabled states.

Contemporary Swift development increasingly uses structured concurrency, actor isolation, dependency injection, and newer testing tools such as Swift Testing. The framework may change, but the underlying principles remain: isolate dependencies, control sources of nondeterminism, test observable contracts, and make failures informative.

Best-Practice Checklist

Before considering a unit or component test complete, ask:

• Does the name describe the behaviour being verified?
• Is the test independent of network, current time, locale, and test order?
• Does it include relevant valid, invalid, and boundary cases?
• Does it verify a meaningful outcome rather than private implementation?
• Are asynchronous operations awaited or explicitly synchronised?
• Are dependencies injected and replaced with appropriate doubles?
• Does a failure provide enough information to diagnose the defect?
• Is sensitive information absent from fixtures and output?
• Does the test remain understandable to another developer?

Chapter Summary

Unit and component testing provides fast, focused evidence that Swift logic and application components behave correctly. Unit tests are best suited to pure functions, models, validators, parsers, and small transformations. Component tests examine view models and services with external dependencies replaced by stubs, spies, fakes, or mocks.

Reliable tests follow Arrange–Act–Assert, use dependency injection, and assert observable behaviour. Boundary tests examine values at and around validity limits. Negative tests cover malformed input, dependency failures, empty results, and invalid state transitions. Error tests should verify safe and meaningful application responses rather than merely detecting that something failed.

Asynchronous tests should await deterministic completion signals instead of relying on arbitrary sleeps. Actor isolation, cancellation, time, randomness, locale, and shared state must be controlled when they affect results. Test smells such as excessive mocking, large tests, duplicated setup, real network calls, and private-detail assertions reduce maintainability. Flaky tests damage confidence and should be repaired at their source.

A professional test suite balances coverage with test quality, protects privacy, supports continuous integration, and concentrates effort on important behaviour. Good tests are not only defect detectors; they are executable specifications and design feedback for the application.

Key Terms

Unit test: A test of a small, focused piece of behaviour in isolation.

Component test: A test of a cohesive application component and its controlled collaborations.

Deterministic test: A test that gives the same result under the same conditions.

Arrange–Act–Assert: A structure that prepares a test, performs the operation, and verifies the result.

Dependency injection: Supplying dependencies from outside rather than constructing them internally.

Protocol: A Swift definition of required capabilities that permits substitutable implementations.

Test double: A replacement object used to control or observe a dependency during testing.

Stub: A test double that returns predetermined data.

Spy: A test double that records interactions for later verification.

Mock: A test double that verifies expected interactions, often strictly.

Fake: A lightweight working implementation used instead of a production dependency.

Boundary test: A test of values at, just inside, or just outside a rule’s limits.

Negative test: A test of invalid input or failure behaviour.

State transition: A change from one observable application state to another.

Flaky test: A test whose result changes unpredictably without a relevant code change.

Test smell: A pattern indicating a test may be fragile, unclear, or difficult to maintain.

Actor isolation: Swift’s mechanism for protecting state and controlling concurrent access.

Deterministic synchronisation: Waiting for an explicit completion signal rather than guessing a duration.

Code coverage: A measure of which instrumented code was executed by tests.

Regression: A previously correct behaviour that becomes defective after a change.

Review Questions

Short Answer Questions

1. What is the difference between a unit test and a component test?
2. Why is dependency injection useful in iOS testing?
3. What is a boundary test? Give one example.
4. Why are arbitrary sleeps discouraged in asynchronous tests?
5. Name three common sources of flaky tests.

Long Answer Questions

1. Explain how Arrange–Act–Assert supports readable and maintainable XCTest code.
2. Describe how you would test a view model that can be idle, loading, loaded, empty, and failed.
3. Compare stubs, spies, mocks, and fakes, and explain when each may be appropriate.
4. Explain why code coverage is useful but insufficient as a complete measure of test quality.
5. Describe the relationship between dependency injection, test isolation, and maintainable application architecture.

Analytical / Application Questions

1. A test calls a real web service and waits two seconds before asserting the result. Identify the test smells and redesign the test approach.
2. A form accepts usernames from 3 through 20 characters inclusive. Design a concise test matrix covering normal values, boundaries, invalid values, and whitespace.
3. A view model changes from loading to loaded even after its request has been cancelled. Analyse the likely defect and propose tests for cancellation and stale-result prevention.

Multiple Choice Questions with Answers

Question 1

Which characteristic is most important for a reliable unit test?

A. It always uses production networking.

B. It is deterministic and focused.

C. It tests every private method separately.

D. It waits for a fixed period before asserting.

Correct Answer: B. It is deterministic and focused.

Question 2

What is the primary purpose of dependency injection in testing?

A. To hide all dependencies from the compiler.

B. To make dependencies replaceable and explicit.

C. To force every test to use a real database.

D. To eliminate the need for assertions.

Correct Answer: B. To make dependencies replaceable and explicit.

Question 3

For a rule accepting values from 3 through 20 inclusive, which value is just outside the lower boundary?

A. 2

B. 3

C. 4

D. 20

Correct Answer: A. 2

Question 4

Which test double records how it was used so that the test can inspect interactions later?

A. Dummy

B. Stub

C. Spy

D. Fixture

Correct Answer: C. Spy

Question 5

Why is an arbitrary asynchronous sleep a poor synchronisation technique?

A. It prevents Swift from compiling async functions.

B. It guarantees that every callback runs twice.

C. It may be too short or unnecessarily long depending on execution conditions.

D. It can only be used with UI tests.

Correct Answer: C. It may be too short or unnecessarily long depending on execution conditions.

Question 6

Which assertion best tests a view model’s error-handling behaviour?

A. The private repository variable exists.

B. The view model enters the appropriate safe error state.

C. The test runs for exactly one second.

D. The networking library has a particular class name.

Correct Answer: B. The view model enters the appropriate safe error state.

Question 7

A test passes alone but fails when the full suite runs. Which cause should be investigated first?

A. Shared mutable state or test-order dependence.

B. The use of Arrange–Act–Assert.

C. The existence of a protocol.

D. The test’s descriptive name.

Correct Answer: A. Shared mutable state or test-order dependence.

Question 8

Which statement about code coverage is correct?

A. 100% coverage proves that the application is correct.

B. Coverage measures whether assertions are logically correct.

C. Coverage can identify unexecuted code but does not by itself demonstrate test quality.

D. Coverage eliminates the need for boundary tests.

Correct Answer: C. Coverage can identify unexecuted code but does not by itself demonstrate test quality.

Question 9

What should a cancellation test verify for an asynchronous view model?

A. That cancellation causes a random delay.

B. That cancelled work cannot incorrectly publish stale results.

C. That every cancelled request succeeds.

D. That the test uses a real server.

Correct Answer: B. That cancelled work cannot incorrectly publish stale results.

Question 10

Which practice most directly reduces environmental flakiness?

A. Using current time and current locale implicitly.

B. Adding longer fixed sleeps to every test.

C. Injecting controllable clocks and replacing external services with test doubles.

D. Running tests only once a month.

Correct Answer: C. Injecting controllable clocks and replacing external services with test doubles.