Unit testing ViewModels in iOS Swift - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the main purpose of unit testing a ViewModel in iOS development?

To verify that the ViewModel correctly processes data and business logic independently from the UI and external dependencies.

beginner

Which Swift testing framework is commonly used for unit testing ViewModels?

XCTest is the standard framework used for unit testing in Swift, including ViewModels.

intermediate

Why should dependencies of a ViewModel be mocked during unit testing?

Mocking dependencies isolates the ViewModel's logic, ensuring tests are fast, reliable, and only fail due to ViewModel issues.

intermediate

What is a common pattern to test asynchronous code in ViewModels?

Using XCTestExpectation to wait for asynchronous operations to complete before asserting results.

intermediate

How can you verify that a ViewModel updates its published properties correctly in SwiftUI?

By observing the published properties and asserting their values after triggering ViewModel actions in tests.

What does mocking a dependency in a ViewModel test help achieve?

A Isolate the ViewModel logic from external factors

B Make the app run faster in production

C Automatically generate UI components

D Replace the ViewModel with a simpler class

Mocking isolates the ViewModel logic so tests focus only on the ViewModel's behavior.

Which XCTest feature helps test asynchronous ViewModel methods?

A XCTAssertNil

B XCTAssertEqual

C XCTFail

D XCTestExpectation

XCTestExpectation waits for async code to finish before assertions.

What is a ViewModel's role in MVVM architecture?

A Manage UI layout and appearance

B Handle business logic and data for the View

C Store user preferences only

D Connect directly to the database

The ViewModel handles business logic and prepares data for the View.

When unit testing a ViewModel, what should you avoid?

A Mocking network calls

B Checking property values

C Testing UI elements directly

D Testing business logic

Unit tests for ViewModels should not test UI elements directly; that belongs to UI tests.

How do you check if a @Published property in a ViewModel changes as expected?

A Observe the property and assert its new value after an action

B Call the property directly without triggering actions

C Use print statements in the ViewModel

D Ignore property changes in tests

Observing and asserting the property after actions confirms correct updates.

Explain how you would write a unit test for a ViewModel method that fetches data asynchronously.

Think about waiting for async calls and controlling dependencies.

Describe why mocking dependencies is important when unit testing ViewModels and how it improves test quality.

Consider how external factors can cause flaky tests.

Practice

1. What is the main purpose of unit testing a ViewModel in iOS development?

easy

A. To verify the app's business logic without involving the user interface

B. To test the app's user interface elements visually

C. To check the app's network connectivity

D. To measure the app's performance speed

Solution

1. Step 1: Understand the role of ViewModel

   The ViewModel handles app logic and data preparation, separate from UI.

2. Step 2: Identify unit testing focus

   Unit testing targets logic correctness without UI involvement.

3. Final Answer:

   To verify the app's business logic without involving the user interface -> Option A

4. Quick Check:

   Unit testing ViewModel = test logic only [OK]

Hint: Unit tests check logic, not UI or performance [OK]

Common Mistakes:

• Confusing unit tests with UI tests
• Thinking unit tests check network or performance
• Assuming ViewModel tests require UI elements

2. Which XCTest method is used to prepare the environment before each test runs in a ViewModel test class?

easy

A. setUp()

B. runTest()

C. testExample()

D. tearDown()

Solution

1. Step 1: Recall XCTest lifecycle methods

   setUp() runs before each test to prepare needed objects.

2. Step 2: Differentiate from tearDown()

   tearDown() cleans up after each test, not before.

3. Final Answer:

   setUp() -> Option A

4. Quick Check:

   Prepare tests before running = setUp() [OK]

Hint: setUp() runs before each test to prepare environment [OK]

Common Mistakes:

• Using tearDown() to prepare tests instead of clean up
• Confusing testExample() as a setup method
• Assuming runTest() is a XCTest lifecycle method

3. Given this ViewModel test code snippet, what will be the value of result after the test runs?

class CounterViewModel {
  var count = 0
  func increment() { count += 1 }
}

func testIncrement() {
  let vm = CounterViewModel()
  vm.increment()
  let result = vm.count
}

medium

A. Compilation error

B. 0

C. nil

D. 1

Solution

1. Step 1: Analyze initial state

   CounterViewModel starts with count = 0.

2. Step 2: Apply increment method

   increment() adds 1 to count, so count becomes 1.

3. Final Answer:

   1 -> Option D

4. Quick Check:

   Increment once = count 1 [OK]

Hint: Increment adds 1, so count becomes 1 [OK]

Common Mistakes:

• Assuming count stays 0 without increment
• Thinking result is nil because of missing return
• Expecting compilation error due to missing test annotation

4. Identify the error in this ViewModel unit test code:

class MyViewModel {
  var value = 0
  func updateValue() { value = 10 }
}

func testUpdateValue() {
  let vm = MyViewModel()
  vm.updateValue()
  XCTAssertEqual(vm.value, 0)
}

medium

A. updateValue() method is missing return type

B. XCTAssertEqual expects 10 but checks for 0

C. MyViewModel class is not marked as final

D. vm instance is not initialized properly

Solution

1. Step 1: Check updateValue() effect

   updateValue() sets value to 10, so vm.value should be 10.

2. Step 2: Compare XCTAssertEqual parameters

   Test expects vm.value to be 0, which is incorrect after updateValue().

3. Final Answer:

   XCTAssertEqual expects 10 but checks for 0 -> Option B

4. Quick Check:

   Test expected value must match updated value [OK]

Hint: Check expected vs actual values in XCTAssertEqual [OK]

Common Mistakes:

• Ignoring the expected value in XCTAssertEqual
• Thinking missing return type causes error here
• Assuming class must be final for testing

5. You want to test a ViewModel method that fetches user data asynchronously and updates a userName property. Which approach correctly tests this behavior using XCTest?

hard

A. Call the method, then immediately assert userName without waiting

B. Test only synchronous methods; skip async ones

C. Use XCTestExpectation to wait for the async update before asserting userName

D. Mock the ViewModel and do not call the real method

Solution

1. Step 1: Understand async testing need

   Async methods update properties after delay, so test must wait.

2. Step 2: Use XCTestExpectation

   Expectation waits for async completion before asserting userName value.

3. Final Answer:

   Use XCTestExpectation to wait for the async update before asserting userName -> Option C

4. Quick Check:

   Async test = use XCTestExpectation [OK]

Hint: Wait for async calls with XCTestExpectation before assertions [OK]

Common Mistakes:

• Asserting async results immediately without waiting
• Skipping async tests thinking they are too complex
• Mocking ViewModel without testing real async behavior