Test doubles (mocks, stubs) in Swift - Step-by-Step Execution

Concept Flow - Test doubles (mocks, stubs)

Start Test

↓

Create Stub

→Stub returns fixed data

↓

Create Mock

→Mock records calls

↓

Run Code Under Test

↓

Verify Mock Calls

↓

Assert Results

↓

Test Ends

The test creates stubs to provide fixed data and mocks to record calls, runs the code, then verifies interactions and results.

Execution Sample

Swift

protocol Service {
  func fetchData() -> String
}

class StubService: Service {
  func fetchData() -> String { "stub data" }
}

class MockService: Service {
  var called = false
  func fetchData() -> String {
    called = true
    return "mock data"
  }
}

Defines a service protocol, a stub returning fixed data, and a mock recording if fetchData() was called.

Execution Table

Step	Action	Stub fetchData() returns	Mock fetchData() called?	Mock fetchData() returns
1	Create StubService instance	N/A	false	N/A
2	Call stub.fetchData()	"stub data"	false	N/A
3	Create MockService instance	N/A	false	N/A
4	Call mock.fetchData()	N/A	true	"mock data"
5	Verify mock.called	N/A	true	N/A
6	Assert stub returns expected data	"stub data"	true	N/A
7	Test ends	N/A	true	N/A

💡 Test ends after verifying mock was called and stub returned expected data.

Variable Tracker

Variable	Start	After Step 2	After Step 4	Final
stub.fetchData() return	N/A	"stub data"	"stub data"	"stub data"
mock.called	false	false	true	true
mock.fetchData() return	N/A	N/A	"mock data"	"mock data"

Key Moments - 3 Insights

Why does the stub return fixed data without changing any state?

Because the stub's fetchData() method always returns the same fixed string, as shown in execution_table step 2, it does not record calls or change variables.

How do we know the mock's fetchData() method was called?

The mock sets its 'called' variable to true when fetchData() runs, shown in execution_table step 4 and variable_tracker mock.called changes from false to true.

Why do we use both a stub and a mock in testing?

The stub provides controlled data for the test, while the mock lets us verify interactions happened, as seen in the flow and execution_table steps 2 and 4.

Visual Quiz - 3 Questions

Look at the execution_table at step 4, what is the value of mock.called after calling fetchData()?

A false

B true

C nil

D "mock data"

💡 Hint

Check the 'Mock fetchData() called?' column at step 4 in execution_table.

At which step does stub.fetchData() return its fixed data?

A Step 1

B Step 4

C Step 2

D Step 5

💡 Hint

Look at the 'Stub fetchData() returns' column in execution_table.

If mock.fetchData() did not set called = true, what would be the value of mock.called at step 5?

A false

B nil

C true

D "mock data"

💡 Hint

Refer to variable_tracker for mock.called changes after step 4.

Concept Snapshot

Test doubles help isolate code during testing.
Stubs provide fixed data without side effects.
Mocks record calls to verify interactions.
Use stubs to control inputs, mocks to check behavior.
Verify mocks after running code under test.

Full Transcript

This visual execution shows how test doubles work in Swift. First, a stub is created that returns fixed data when fetchData() is called. Then a mock is created that records if fetchData() was called by setting a boolean variable. The code under test calls these methods. We track the stub returning fixed data and the mock recording the call. Finally, the test verifies the mock was called and the stub returned expected data. This helps isolate and check code behavior during 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