Why Test doubles (mocks, stubs) in Swift? - Purpose & Use Cases

The Big Idea

What if you could test your app perfectly without depending on real-world signals or slow services?

The Scenario

Imagine you are testing a car's navigation app that needs live GPS data and internet maps. Without test doubles, you must rely on real GPS signals and internet connections every time you test.

The Problem

This manual way is slow and unreliable. If GPS is weak or internet is down, your tests fail even if your code is fine. Also, you can't easily test rare cases like wrong locations or no signal.

The Solution

Test doubles like mocks and stubs act as pretend parts. They give fixed GPS data or fake internet responses instantly. This makes tests fast, reliable, and lets you check how your app handles all situations.

Before vs After

✗ Before

let location = realGPS.getLocation()
let map = realInternet.fetchMap(location)

✓ After

let location = stubGPS.getFixedLocation()
let map = mockInternet.fetchFakeMap(location)

What It Enables

Test doubles let you test your code anytime, anywhere, and for every possible case without waiting or failing due to outside problems.

Real Life Example

When building a weather app, you can use stubs to simulate sunny or rainy weather data, so you see how your app looks without waiting for actual weather changes.

Key Takeaways

Manual testing with real parts is slow and unreliable.

Test doubles replace real parts with pretend ones for fast, stable tests.

This helps test all scenarios easily and confidently.

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