Test doubles (mocks, stubs) in Swift - Deep Dive

Overview - Test doubles (mocks, stubs)

What is it?

Test doubles are fake objects used in software testing to replace real parts of a program. They help simulate behaviors of complex or external components like databases or web services. Mocks and stubs are types of test doubles that let you control and check how your code interacts with these parts. This makes testing easier and more reliable.

Why it matters

Without test doubles, tests would depend on real external systems, making them slow, flaky, or hard to run anywhere. Test doubles let you isolate the code you want to test, so you can find bugs faster and trust your tests. This improves software quality and developer confidence.

Where it fits

Before learning test doubles, you should understand basic unit testing and how functions or classes interact. After this, you can explore advanced testing techniques like spies, fakes, and integration testing to cover more complex scenarios.

Mental Model

Core Idea

Test doubles stand in for real components during testing to control behavior and verify interactions without using the actual parts.

Think of it like...

Imagine rehearsing a play where some actors are replaced by stand-ins who follow a script exactly, so the main actors can practice without distractions or surprises.

┌─────────────┐       ┌─────────────┐
│   Real      │       │   Test      │
│ Component   │       │ Double      │
│ (Database)  │       │ (Stub/Mock) │
└─────┬───────┘       └─────┬───────┘
      │                     │
      │ Used in production   │ Used in tests
      │                     │
┌─────▼───────┐       ┌─────▼───────┐
│ Application │──────▶│ Application │
│   Code      │       │   Code      │
└─────────────┘       └─────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Unit Testing Basics

Concept: Learn what unit tests are and why we write them to check small parts of code.

Unit tests check if a small piece of code, like a function or class, works correctly by itself. They run automatically and tell you if something breaks. For example, testing a function that adds two numbers to make sure it returns the right sum.

Result

You know how to write simple tests that check code behavior.

Understanding unit tests is essential because test doubles only make sense when you want to isolate parts of code during these tests.

2

Foundation

Why Real Dependencies Hurt Tests

Concept: Real external parts like databases or web services can make tests slow and unreliable.

If your test talks to a real database, it might fail if the database is down or slow. This makes tests flaky and hard to run often. Also, real dependencies can make tests slow, so you avoid running them frequently.

Result

You see why relying on real parts in tests is a problem.

Knowing the downsides of real dependencies motivates the need for test doubles to keep tests fast and stable.

3

Intermediate

Introducing Stubs for Controlled Responses

🤔Before reading on: do you think a stub can record how it was called, or just provide fixed answers? Commit to your answer.

Concept: Stubs are test doubles that provide preset answers to calls but don’t track how they were used.

A stub replaces a real component and returns fixed data when called. For example, a stub database might always return the same user info. It helps test how your code behaves with known data without using the real database.

Result

You can control test inputs by replacing parts with stubs.

Understanding stubs helps you isolate your code by controlling external data, making tests predictable.

4

Intermediate

Using Mocks to Verify Interactions

🤔Before reading on: do you think mocks only provide data, or can they also check if certain methods were called? Commit to your answer.

Concept: Mocks are test doubles that both provide data and record how they were used, letting you check interactions.

Mocks act like stubs but also remember which methods were called and with what arguments. For example, a mock logger can check if your code logged an error message. This verifies not just outputs but behavior.

Result

You can test if your code talks to other parts correctly.

Knowing mocks lets you test not only results but also how your code behaves with other components.

5

Intermediate

Creating Test Doubles in Swift

Concept: Learn how to write simple stubs and mocks in Swift using protocols and classes.

In Swift, define a protocol for the component you want to replace. Then create a stub or mock class that implements this protocol. For example: protocol UserService { func fetchUser(id: String) -> User? } class UserServiceStub: UserService { func fetchUser(id: String) -> User? { return User(id: id, name: "Test User") } } Use this stub in your tests instead of the real service.

Result

You can write your own test doubles in Swift to isolate tests.

Understanding how to create test doubles in your language is key to applying these concepts in real projects.

6

Advanced

Combining Multiple Test Doubles

🤔Before reading on: do you think mixing mocks and stubs in one test is confusing or helpful? Commit to your answer.

Concept: Tests often use both stubs and mocks together to control data and verify behavior.

For example, you might stub a database to return fixed data and mock a logger to check if errors are logged. Combining them lets you test complex scenarios where you control inputs and check outputs and interactions.

Result

You can write richer tests that cover more cases.

Knowing how to combine test doubles helps you write thorough tests that catch subtle bugs.

7

Expert

Avoiding Overuse and Test Fragility

🤔Before reading on: do you think using many mocks makes tests more stable or more fragile? Commit to your answer.

Concept: Excessive use of mocks can make tests fragile and tightly coupled to implementation details.

If you mock too many internal calls, your tests break when you change code structure, even if behavior stays correct. Experts balance mocks and real objects to keep tests meaningful and maintainable. They also use techniques like dependency injection and test spies.

Result

You understand when mocks help and when they hurt test quality.

Knowing the limits of mocks prevents wasted effort on brittle tests and encourages better design.

Under the Hood

Test doubles work by replacing real objects with fake ones that implement the same interface or protocol. During test runs, the program calls these fakes instead of real components. Stubs return preset data immediately, while mocks record calls and arguments in memory. This lets the test check if expected interactions happened. The test framework manages these objects and verifies their behavior after the test code runs.

Why designed this way?

Test doubles were created to solve the problem of slow, unreliable tests caused by real dependencies. Early testing struggled with external systems that were hard to control. By designing doubles that mimic interfaces, developers could isolate code and test it independently. This approach balances realism and control, avoiding the complexity of full system tests for every change.

┌───────────────┐
│ Test Runner   │
└──────┬────────┘
       │
       ▼
┌───────────────┐       ┌───────────────┐
│ Test Code     │──────▶│ Test Double   │
│ (Calls API)   │       │ (Stub/Mock)   │
└───────────────┘       └──────┬────────┘
                                │
                                ▼
                      ┌─────────────────┐
                      │ Real Component   │
                      │ (Replaced in test)│
                      └─────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do mocks only provide fake data, or can they also check how they were used? Commit to your answer.

Common Belief: Mocks are just fake objects that return data like stubs.

Reality: Mocks also record how they were called, letting tests verify interactions, not just outputs.

Why it matters: Thinking mocks only provide data leads to missing bugs where code calls wrong methods or misses calls.

Quick: Is it always better to mock every dependency in a test? Commit to yes or no.

Common Belief: More mocks always make tests better and more isolated.

Reality: Over-mocking can make tests fragile and tightly coupled to code details, causing frequent breaks on refactoring.

Why it matters: Excessive mocking wastes time fixing tests that break without real bugs, reducing developer trust.

Quick: Do stubs track how they were called? Commit to yes or no.

Common Belief: Stubs can record calls and verify interactions like mocks.

Reality: Stubs only provide fixed responses and do not track usage; only mocks do that.

Why it matters: Confusing stubs and mocks can lead to wrong test designs and missed verification.

Quick: Can test doubles replace all types of dependencies equally well? Commit to yes or no.

Common Belief: Test doubles can perfectly replace any dependency in tests.

Reality: Some dependencies, like complex UI or hardware, are hard to double accurately and may need other testing strategies.

Why it matters: Expecting test doubles to solve all testing problems can lead to incomplete test coverage.

Expert Zone

1

Mocks should verify behavior, not implementation details, to keep tests resilient to refactoring.

2

Using protocols in Swift enables easy swapping of real and test doubles without changing code.

3

Test doubles can be combined with dependency injection to improve test flexibility and reduce boilerplate.

When NOT to use

Avoid test doubles when testing full system integration or user interfaces where real components provide essential feedback. Instead, use integration or UI tests. Also, avoid overusing mocks in simple logic tests where real objects are lightweight and stable.

Production Patterns

In production, test doubles are used with dependency injection frameworks to swap real services with mocks or stubs during tests. Teams often create reusable mock classes for common dependencies like network clients or databases. Continuous integration runs tests with doubles to ensure fast feedback without external dependencies.

Connections

Dependency Injection

Test doubles rely on dependency injection to replace real components with fakes during tests.

Understanding dependency injection helps you see how test doubles fit into flexible, testable code design.

Behavior-Driven Development (BDD)

Mocks are often used in BDD to verify that code behaves as expected by checking interactions.

Knowing how mocks support BDD clarifies their role in specifying and validating software behavior.

Theater Rehearsal

Both test doubles and theater stand-ins replace real actors to allow focused practice.

Recognizing this connection highlights the importance of controlled environments for learning and testing.

Common Pitfalls

#1 Using real database in unit tests causing slow and flaky tests.

Wrong approach:

func testUserFetch() {
let realDB = RealDatabase()
let service = UserService(database: realDB)
let user = service.fetchUser(id: "123")
XCTAssertEqual(user?.name, "Alice")
}

Correct approach:

func testUserFetch() {
let stubDB = UserServiceStub()
let service = UserService(database: stubDB)
let user = service.fetchUser(id: "123")
XCTAssertEqual(user?.name, "Test User")
}

Root cause:

Not isolating tests from slow or unreliable external dependencies.

#2 Mocking too many internal calls making tests fragile.

Wrong approach:

class UserServiceMock: UserService {
func fetchUser(id: String) -> User? {
mock.verifyCalled("fetchUser")
return User(id: id, name: "Mock")
}
}
// Test breaks if internal calls change.

Correct approach:

Use mocks only for external dependencies and test behavior, not internal implementation details.

Root cause:

Confusing unit test boundaries and over-coupling tests to code structure.

#3 Using stub when interaction verification is needed.

Wrong approach:

class LoggerStub: Logger {
func log(_ message: String) {
// Does nothing
}
}
// Test cannot check if log was called.

Correct approach:

class LoggerMock: Logger {
var messages = [String]()
func log(_ message: String) {
messages.append(message)
}
}
// Test can verify logged messages.

Root cause:

Misunderstanding difference between stubs and mocks.

Key Takeaways

Test doubles replace real components in tests to make them faster, reliable, and isolated.

Stubs provide fixed responses but do not track usage; mocks also record calls to verify behavior.

Creating test doubles in Swift involves protocols and fake classes that implement them.

Overusing mocks can make tests fragile; balance is key for maintainable tests.

Test doubles work best with dependency injection and are essential for effective unit testing.

Practice

1. What is the main purpose of using a mock in Swift testing?

easy

A. To record how a function was called during a test

B. To provide fixed data without recording calls

C. To replace the entire app with a test version

D. To speed up the app in production

Solution

1. Step 1: Understand what a mock does

   A mock is a test double that records how it was used, such as which methods were called and with what arguments.

2. Step 2: Compare with other test doubles

   Unlike stubs, mocks focus on interaction verification, not just providing fixed answers.

3. Final Answer:

   To record how a function was called during a test -> Option A

4. Quick Check:

   Mock = Records calls [OK]

Hint: Mocks remember calls; stubs just return data [OK]

Common Mistakes:

• Confusing mocks with stubs
• Thinking mocks speed up production
• Believing mocks replace the whole app

2. Which of the following is the correct way to define a stub method in Swift that always returns 42?

easy

A. func getNumber() -> Int { return 42 }

B. func getNumber() -> Int { print(42) }

C. func getNumber() { return 42 }

D. func getNumber() -> String { return "42" }

Solution

1. Step 1: Check method signature and return type

   The method must return an Int, so the signature should be func getNumber() -> Int.

2. Step 2: Verify the return statement

   The method should return the integer 42, so return 42 is correct.

3. Final Answer:

   func getNumber() -> Int { return 42 } -> Option A

4. Quick Check:

   Stub returns fixed value [OK]

Hint: Stub methods return fixed values with correct return type [OK]

Common Mistakes:

• Missing return type in function signature
• Returning wrong data type
• Using print instead of return

3. Consider this Swift mock class snippet:

class ServiceMock {
    var fetchCalled = false
    func fetchData() {
        fetchCalled = true
    }
}

let mock = ServiceMock()
mock.fetchData()
print(mock.fetchCalled)

What will be printed?

medium

A. false

B. true

C. nil

D. Compilation error

Solution

1. Step 1: Understand the mock class behavior

   The class has a boolean property fetchCalled initially false. The method fetchData() sets it to true.

2. Step 2: Trace the code execution

   After creating mock, calling mock.fetchData() sets fetchCalled to true. Printing it outputs true.

3. Final Answer:

   true -> Option B

4. Quick Check:

   Mock records call = true [OK]

Hint: Mock flags change after method call [OK]

Common Mistakes:

• Assuming fetchCalled stays false
• Expecting nil instead of Bool
• Thinking code won't compile

4. This Swift stub class is intended to return a fixed string but has a bug:

class DataStub {
    func getData() -> String {
        print("Fixed data")
    }
}

What is the error and how to fix it?

medium

A. print cannot be used in stubs; remove print

B. Wrong method name; rename to fetchData()

C. Return type should be Void; change signature

D. Missing return statement; add return "Fixed data"

Solution

1. Step 1: Identify the method signature and body

   The method declares it returns a String but only calls print without returning anything.

2. Step 2: Fix the missing return

   Replace print("Fixed data") with return "Fixed data" to satisfy the return type.

3. Final Answer:

   Missing return statement; add return "Fixed data" -> Option D

4. Quick Check:

   Stub must return value, not print [OK]

Hint: Return values, don't print in stubs [OK]

Common Mistakes:

• Confusing print with return
• Changing method name unnecessarily
• Changing return type incorrectly

5. You want to test a Swift class Downloader that calls a network service. To avoid real network calls, you create a mock service that records if download() was called and a stub that returns fixed data. Which approach correctly combines mocks and stubs for this test?

hard

A. Use only a mock that returns fixed data without recording calls

B. Use only a stub that records calls and returns data

C. Use a mock to record download() calls and a stub to return fixed data when fetchData() is called

D. Use real network service to ensure accurate testing

Solution

1. Step 1: Understand roles of mocks and stubs

   Mocks record interactions like method calls; stubs provide fixed return data.

2. Step 2: Apply correct combination

   Use a mock to check if download() was called, and a stub to supply fixed data for fetchData() to avoid real network calls.

3. Final Answer:

   Use a mock to record download() calls and a stub to return fixed data when fetchData() is called -> Option C

4. Quick Check:

   Mock records calls + Stub returns data [OK]

Hint: Mocks track calls; stubs provide data [OK]

Common Mistakes:

• Using only one test double type
• Relying on real network in tests
• Confusing mock and stub roles