How do I unit test SwiftUI ViewModels?

Create your ViewModel with mock dependencies injected via protocol-based dependency injection. Call ViewModel methods in your test, then assert on published properties. Use @Observable ViewModels for simpler testing — just check property values directly without Combine subscribers.

How do I test async/await functions in XCTest?

Mark your test function as async: func testExample() async throws. Then directly await the async function and assert on the result. For testing async sequences or publishers, use XCTestExpectation with fulfillment or the newer Swift Testing framework's confirmation API.

What is the difference between unit tests and UI tests in iOS?

Unit tests (XCTest) run in-process and test individual functions, ViewModels, and services in isolation. They are fast (milliseconds). UI tests (XCUITest) launch your app in a separate process and simulate user interactions. They are slow (seconds) but verify the full user flow.

How do I mock network requests in Swift tests?

Use protocol-based dependency injection. Define a protocol for your network service, create a mock implementation that returns predefined data, and inject the mock in tests. Alternatively, use URLProtocol subclassing to intercept URLSession requests at the network level.

SwiftUI Unit Testing Guide — XCTest, ViewModels & Async Testing (2026)

Why Unit Testing Matters for SwiftUI Apps

According to a 2025 Bitrise study across 10,000 iOS projects, apps with over 60% unit test coverage experience 74% fewer production crashes and spend 40% less time on bug fixes per release. That is not theory — it is data.

SwiftUI makes testing simultaneously easier and harder than UIKit. Easier because MVVM naturally separates business logic from views. Harder because SwiftUI views are structs without lifecycle methods, so traditional UI testing does not apply. The good news: if you structure your app correctly — @Observable ViewModels, protocol-based dependency injection, thin views — you can achieve 80%+ coverage without touching a UI test.

XCTest Fundamentals

XCTest ships with Xcode. Every test file is a class inheriting from XCTestCase with methods prefixed with test. Xcode discovers them automatically when you press Cmd + U.

import XCTest
@testable import MyApp

final class BasicTests: XCTestCase {
    override func setUp() {
        super.setUp()
        // Runs before EACH test method
    }

    override func tearDown() {
        super.tearDown()
        // Runs after EACH test — clean up here
    }

    func testAddition() {
        // Arrange
        let calculator = Calculator()
        // Act
        let result = calculator.add(2, 3)
        // Assert
        XCTAssertEqual(result, 5, "2 + 3 should equal 5")
    }
}

XCTest Assertion Methods Reference

Assertion	What It Checks	Common Use Case
`XCTAssertEqual(a, b)`	a == b	Verify computed values, state after action
`XCTAssertNotEqual(a, b)`	a != b	Verify state changed after mutation
`XCTAssertTrue(expr)`	Expression is true	Boolean flags, feature toggles
`XCTAssertFalse(expr)`	Expression is false	Verify loading ended, error cleared
`XCTAssertNil(expr)`	Expression is nil	No error after success, cleared state
`XCTAssertNotNil(expr)`	Expression is not nil	Object created, data loaded
`XCTAssertGreaterThan(a, b)`	a > b	Array has items, count increased
`XCTAssertThrowsError(expr)`	Expression throws	Invalid input, network failures
`XCTAssertNoThrow(expr)`	No error thrown	Valid input succeeds
`XCTAssertIdentical(a, b)`	Same reference (===)	Singleton identity, cache hits
`XCTAssertEqual(a, b, accuracy:)`	Float equality within tolerance	Calculations, currency rounding
`XCTFail("msg")`	Unconditional failure	Code path that should never execute

Testing @Observable ViewModels

ViewModels are where most tests should live. They contain business logic and manage state transitions. With protocol-based DI as described in our architecture guide, testing becomes straightforward. Here is a ViewModel with its protocol, mock, and full test suite:

// Protocols/RecipeServiceProtocol.swift
protocol RecipeServiceProtocol: Sendable {
    func fetchAll() async throws -> [Recipe]
    func update(_ recipe: Recipe) async throws
    func delete(id: UUID) async throws
}

// ViewModels/RecipeListViewModel.swift
@MainActor @Observable
final class RecipeListViewModel {
    private(set) var recipes: [Recipe] = []
    private(set) var isLoading = false
    private(set) var errorMessage: String?
    var searchQuery = ""

    private let service: RecipeServiceProtocol

    init(service: RecipeServiceProtocol) {
        self.service = service
    }

    var filteredRecipes: [Recipe] {
        guard !searchQuery.isEmpty else { return recipes }
        return recipes.filter {
            $0.title.localizedCaseInsensitiveContains(searchQuery)
        }
    }

    func loadRecipes() async {
        isLoading = true
        errorMessage = nil
        do {
            recipes = try await service.fetchAll()
        } catch {
            errorMessage = error.localizedDescription
        }
        isLoading = false
    }

    func deleteRecipe(_ recipe: Recipe) async {
        let backup = recipes
        recipes.removeAll { $0.id == recipe.id }
        do {
            try await service.delete(id: recipe.id)
        } catch {
            recipes = backup
            errorMessage = "Failed to delete recipe."
        }
    }

    func toggleFavorite(_ recipe: Recipe) async {
        guard let idx = recipes.firstIndex(where: { $0.id == recipe.id }) else { return }
        recipes[idx].isFavorite.toggle()
        do {
            try await service.update(recipes[idx])
        } catch {
            recipes[idx].isFavorite.toggle()
            errorMessage = "Could not update favorite status."
        }
    }
}

The Mock Service

// Mocks/MockRecipeService.swift
final class MockRecipeService: RecipeServiceProtocol, @unchecked Sendable {
    var stubbedRecipes: [Recipe] = []
    var shouldThrowOnFetch = false
    var shouldThrowOnDelete = false
    var shouldThrowOnUpdate = false
    var deletedIDs: [UUID] = []
    var updatedRecipes: [Recipe] = []

    func fetchAll() async throws -> [Recipe] {
        if shouldThrowOnFetch {
            throw NSError(domain: "test", code: 1,
                userInfo: [NSLocalizedDescriptionKey: "Fetch failed"])
        }
        return stubbedRecipes
    }

    func update(_ recipe: Recipe) async throws {
        if shouldThrowOnUpdate {
            throw NSError(domain: "test", code: 2,
                userInfo: [NSLocalizedDescriptionKey: "Update failed"])
        }
        updatedRecipes.append(recipe)
    }

    func delete(id: UUID) async throws {
        if shouldThrowOnDelete {
            throw NSError(domain: "test", code: 3,
                userInfo: [NSLocalizedDescriptionKey: "Delete failed"])
        }
        deletedIDs.append(id)
    }
}

The Complete Test Suite

@MainActor
final class RecipeListViewModelTests: XCTestCase {
    private var mockService: MockRecipeService!
    private var viewModel: RecipeListViewModel!

    override func setUp() {
        super.setUp()
        mockService = MockRecipeService()
        viewModel = RecipeListViewModel(service: mockService)
    }

    func testLoadRecipesSuccess() async {
        // Arrange
        mockService.stubbedRecipes = [
            Recipe(id: UUID(), title: "Pasta Carbonara",
                   ingredients: ["pasta", "eggs"], instructions: "Cook",
                   tags: ["italian"], isFavorite: false, createdAt: Date()),
        ]
        // Act
        await viewModel.loadRecipes()
        // Assert
        XCTAssertEqual(viewModel.recipes.count, 1)
        XCTAssertFalse(viewModel.isLoading)
        XCTAssertNil(viewModel.errorMessage)
    }

    func testLoadRecipesFailure() async {
        mockService.shouldThrowOnFetch = true
        await viewModel.loadRecipes()
        XCTAssertNotNil(viewModel.errorMessage)
        XCTAssertTrue(viewModel.recipes.isEmpty)
        XCTAssertFalse(viewModel.isLoading)
    }

    func testFilteredRecipesByTitle() async {
        mockService.stubbedRecipes = [
            Recipe(id: UUID(), title: "Pasta", ingredients: [],
                   instructions: "", tags: [], isFavorite: false, createdAt: Date()),
            Recipe(id: UUID(), title: "Sushi", ingredients: [],
                   instructions: "", tags: [], isFavorite: false, createdAt: Date()),
        ]
        await viewModel.loadRecipes()
        viewModel.searchQuery = "pasta"
        XCTAssertEqual(viewModel.filteredRecipes.count, 1)
        XCTAssertEqual(viewModel.filteredRecipes.first?.title, "Pasta")
    }

    func testDeleteRecipeOptimistic() async {
        let id = UUID()
        mockService.stubbedRecipes = [
            Recipe(id: id, title: "Delete Me", ingredients: [],
                   instructions: "", tags: [], isFavorite: false, createdAt: Date()),
        ]
        await viewModel.loadRecipes()
        await viewModel.deleteRecipe(viewModel.recipes[0])
        XCTAssertTrue(viewModel.recipes.isEmpty)
        XCTAssertEqual(mockService.deletedIDs, [id])
    }

    func testDeleteRecipeRollbackOnFailure() async {
        let recipe = Recipe(id: UUID(), title: "Keep", ingredients: [],
                            instructions: "", tags: [], isFavorite: false, createdAt: Date())
        mockService.stubbedRecipes = [recipe]
        await viewModel.loadRecipes()
        mockService.shouldThrowOnDelete = true
        await viewModel.deleteRecipe(recipe)
        XCTAssertEqual(viewModel.recipes.count, 1, "Should rollback on failure")
        XCTAssertNotNil(viewModel.errorMessage)
    }

    func testToggleFavoriteSuccess() async {
        let recipe = Recipe(id: UUID(), title: "Tacos", ingredients: [],
                            instructions: "", tags: [], isFavorite: false, createdAt: Date())
        mockService.stubbedRecipes = [recipe]
        await viewModel.loadRecipes()
        await viewModel.toggleFavorite(viewModel.recipes[0])
        XCTAssertTrue(viewModel.recipes[0].isFavorite)
    }

    func testToggleFavoriteRollbackOnFailure() async {
        let recipe = Recipe(id: UUID(), title: "Tacos", ingredients: [],
                            instructions: "", tags: [], isFavorite: false, createdAt: Date())
        mockService.stubbedRecipes = [recipe]
        await viewModel.loadRecipes()
        mockService.shouldThrowOnUpdate = true
        await viewModel.toggleFavorite(viewModel.recipes[0])
        XCTAssertFalse(viewModel.recipes[0].isFavorite, "Should rollback")
    }
}

Testing Async/Await Functions

Swift's native concurrency makes async testing clean. Mark your test async and await the result — XCTest handles the rest. For legacy callback APIs, use XCTestExpectation:

// Modern async — preferred
func testFetchUserAsync() async throws {
    let service = MockUserService()
    service.stubbedUser = User(id: UUID(), name: "Alice", email: "alice@test.com")
    let user = try await service.fetchProfile(id: service.stubbedUser!.id)
    XCTAssertEqual(user.name, "Alice")
}

// Legacy callback — use only when async wrapper unavailable
func testCallbackAPI() {
    let expectation = expectation(description: "Callback fires")
    let service = LegacyService()
    service.fetchData { result in
        switch result {
        case .success(let data):
            XCTAssertFalse(data.isEmpty)
        case .failure(let error):
            XCTFail("Expected success, got \(error)")
        }
        expectation.fulfill()
    }
    waitForExpectations(timeout: 5.0)
}

Dependency Injection for Testability

The single most important design decision for testable code: every external dependency goes behind a protocol. Your ViewModels depend on the protocol, not the concrete class. In tests you inject mocks. In production you inject the real thing.

// Protocol
protocol AuthServiceProtocol: Sendable {
    func signIn(email: String, password: String) async throws -> User
    func signOut() async throws
    var currentUser: User? { get }
}

// Mock for tests
final class MockAuthService: AuthServiceProtocol, @unchecked Sendable {
    var stubbedUser: User?
    var shouldThrow = false
    var signInCallCount = 0

    func signIn(email: String, password: String) async throws -> User {
        signInCallCount += 1
        if shouldThrow { throw AuthError.invalidCredentials }
        guard let user = stubbedUser else { throw AuthError.invalidCredentials }
        return user
    }
    func signOut() async throws {}
    var currentUser: User? { stubbedUser }
}

// ViewModel depends on protocol, not concrete class
@MainActor @Observable
final class LoginViewModel {
    private let authService: AuthServiceProtocol
    init(authService: AuthServiceProtocol) {
        self.authService = authService
    }
}

Rule of thumb: if a class talks to anything outside your process — network, disk, Keychain, UserDefaults — it should be behind a protocol. This is not over-engineering. It is the minimum investment that makes unit testing possible.

Testing Combine Publishers

Even with @Observable replacing ObservableObject, Combine still appears in networking layers and reactive pipelines:

import Combine

final class SearchServiceTests: XCTestCase {
    private var cancellables = Set<AnyCancellable>()

    func testDebouncedSearch() {
        let expectation = expectation(description: "Debounced result")
        let subject = PassthroughSubject<String, Never>()
        var results: [String] = []

        subject
            .debounce(for: .milliseconds(300), scheduler: DispatchQueue.main)
            .removeDuplicates()
            .sink { query in
                results.append(query)
                if results.count == 1 { expectation.fulfill() }
            }
            .store(in: &cancellables)

        subject.send("S")
        subject.send("Sw")
        subject.send("Swift")

        waitForExpectations(timeout: 2.0)
        XCTAssertEqual(results, ["Swift"], "Debounce should collapse to final value")
    }
}

Testing Network Layers with URLProtocol

Intercept URLSession requests at the protocol level — no third-party library needed:

final class MockURLProtocol: URLProtocol {
    static var requestHandler: ((URLRequest) throws -> (HTTPURLResponse, Data))?

    override class func canInit(with request: URLRequest) -> Bool { true }
    override class func canonicalRequest(for request: URLRequest) -> URLRequest { request }

    override func startLoading() {
        guard let handler = MockURLProtocol.requestHandler else {
            XCTFail("No handler set"); return
        }
        do {
            let (response, data) = try handler(request)
            client?.urlProtocol(self, didReceive: response, cacheStoragePolicy: .notAllowed)
            client?.urlProtocol(self, didLoad: data)
            client?.urlProtocolDidFinishLoading(self)
        } catch {
            client?.urlProtocol(self, didFailWithError: error)
        }
    }
    override func stopLoading() {}
}

// Usage
final class APIClientTests: XCTestCase {
    private var session: URLSession!

    override func setUp() {
        let config = URLSessionConfiguration.ephemeral
        config.protocolClasses = [MockURLProtocol.self]
        session = URLSession(configuration: config)
    }

    func testFetchRecipesDecodes() async throws {
        let json = [["id": UUID().uuidString, "title": "Test Recipe"]]
        let data = try JSONSerialization.data(withJSONObject: json)
        MockURLProtocol.requestHandler = { request in
            let response = HTTPURLResponse(url: request.url!, statusCode: 200,
                                           httpVersion: nil, headerFields: nil)!
            return (response, data)
        }
        let client = APIClient(session: session)
        let recipes = try await client.fetchRecipes()
        XCTAssertEqual(recipes.first?.title, "Test Recipe")
    }
}

Testing Core Data and SwiftData Models

Use an in-memory store so tests run fast and do not pollute each other:

import SwiftData

@MainActor
final class RecipeStorageTests: XCTestCase {
    private var container: ModelContainer!

    override func setUp() {
        let config = ModelConfiguration(isStoredInMemoryOnly: true)
        container = try! ModelContainer(for: RecipeModel.self, configurations: config)
    }

    func testInsertAndFetch() throws {
        let context = container.mainContext
        let recipe = RecipeModel(title: "Pancakes", ingredients: "flour, eggs",
                                 instructions: "Mix and fry")
        context.insert(recipe)
        try context.save()

        let descriptor = FetchDescriptor<RecipeModel>(
            predicate: #Predicate { $0.title == "Pancakes" }
        )
        let results = try context.fetch(descriptor)
        XCTAssertEqual(results.count, 1)
    }
}

Snapshot Testing with swift-snapshot-testing

Unit tests verify logic. Snapshot tests verify appearance. PointFree's swift-snapshot-testing captures a pixel-perfect image and compares it against a stored reference. If anything changes, the test fails with a visual diff.

// Package dependency: pointfreeco/swift-snapshot-testing from: "1.17.0"
import SnapshotTesting
import SwiftUI

final class RecipeCardSnapshotTests: XCTestCase {
    func testRecipeCardLightMode() {
        let view = RecipeCard(recipe: .sample)
            .environment(\.colorScheme, .light)
            .frame(width: 375)
        let controller = UIHostingController(rootView: view)
        assertSnapshot(of: controller, as: .image(on: .iPhone13))
    }

    func testRecipeCardDarkMode() {
        let view = RecipeCard(recipe: .sample)
            .environment(\.colorScheme, .dark)
            .frame(width: 375)
        let controller = UIHostingController(rootView: view)
        assertSnapshot(of: controller, as: .image(on: .iPhone13))
    }

    func testAccessibilityExtraLarge() {
        let view = RecipeCard(recipe: .sample)
            .environment(\.sizeCategory, .accessibilityExtraLarge)
            .frame(width: 375)
        let controller = UIHostingController(rootView: view)
        assertSnapshot(of: controller, as: .image(on: .iPhone13))
    }
}

Tip: use fixed dates and deterministic data in snapshot tests. If your view displays "3 minutes ago," the snapshot will fail on every run. Pass a fixed Date instead.

UI Testing Basics with XCUITest

XCUITest launches your app in a separate process and interacts with it like a user. Slower and more brittle than unit tests, so reserve it for critical flows:

final class LoginFlowUITests: XCTestCase {
    private var app: XCUIApplication!

    override func setUp() {
        continueAfterFailure = false
        app = XCUIApplication()
        app.launchArguments = ["--uitesting"]
        app.launch()
    }

    func testSuccessfulLogin() {
        app.textFields["emailTextField"].tap()
        app.textFields["emailTextField"].typeText("test@example.com")
        app.secureTextFields["passwordTextField"].tap()
        app.secureTextFields["passwordTextField"].typeText("password123")
        app.buttons["loginButton"].tap()

        let homeTitle = app.staticTexts["homeTitle"]
        XCTAssertTrue(homeTitle.waitForExistence(timeout: 5))
    }
}

// In your @main App struct, swap in mock services for UI tests:
// if CommandLine.arguments.contains("--uitesting") {
//     container = DIContainer.mock
// }

Testing Approaches Compared

Approach	Speed	Scope	Reliability	Best For	Count
Unit Tests	Milliseconds	Single function/class	Very high	ViewModel logic, services, models	Hundreds
Integration Tests	Seconds	Multiple components	High	ViewModel + database, API client + URLSession	Dozens
Snapshot Tests	Seconds	Visual rendering	Medium	Design consistency, dark mode, accessibility	Dozens
UI Tests (XCUITest)	10-60s each	Full app	Lower	Critical flows: login, purchase, onboarding	5-15

The testing pyramid applies to iOS: many unit tests at the base, fewer integration tests in the middle, a handful of UI tests at the top. If you are writing more UI tests than unit tests, your architecture is not separating concerns well enough.

Test Organization: Arrange-Act-Assert

Every test in this guide follows Arrange-Act-Assert (AAA):

Arrange: set up test data, create mocks, configure the system under test.
Act: perform the single action you are testing. One method call, one state change.
Assert: verify the outcome. Multiple assertions are fine if they verify different aspects of the same action.

Name tests descriptively: testDeleteRecipeRollbackOnFailure tells you exactly what broke when CI fails. Avoid names like testDelete1.

Test File Structure

MyAppTests/
├── Mocks/
│   ├── MockRecipeService.swift
│   ├── MockAuthService.swift
│   └── MockURLProtocol.swift
├── ViewModels/
│   ├── RecipeListViewModelTests.swift
│   ├── LoginViewModelTests.swift
│   └── ProfileViewModelTests.swift
├── Services/
│   ├── RecipeValidatorTests.swift
│   └── APIClientTests.swift
├── Models/
│   └── RecipeTests.swift
├── Helpers/
│   └── TestFixtures.swift
└── Snapshots/
    ├── RecipeCardSnapshotTests.swift
    └── __Snapshots__/

Code Coverage Strategy

Enable coverage in Edit Scheme > Test > Options > Code Coverage. Here is what to aim for:

ViewModels: 80-90%. Most business logic lives here. High coverage pays off.
Services/Repositories: 70-80%. Test main paths and error handling.
Models: 60-70%. Test computed properties and Codable conformance.
Views: 10-30%. Do not unit-test SwiftUI views directly. Test their ViewModels and use snapshot tests for visuals.
Overall: 60-75%. Above 80% usually means you are testing trivial code.

Coverage is a metric, not a goal. 50% coverage with well-chosen tests can be more effective than 90% of trivial code. Test the logic that handles money, the async flows that are hardest to debug, and the code that scares you.

CI/CD Testing with Xcode Cloud

Running tests on every pull request is where testing truly pays off. Xcode Cloud makes this easy:

Go to Product > Xcode Cloud > Create Workflow. Trigger on PRs to main.
Add a Test action targeting the latest iOS and one version back.
Add a ci_scripts/ci_post_clone.sh for any custom setup (SwiftGen, etc.).

Xcode Cloud gives 25 free compute hours per month — enough for most indie projects. Alternatively, use GitHub Actions:

# .github/workflows/test.yml
name: Run Tests
on:
  pull_request:
    branches: [main]
jobs:
  test:
    runs-on: macos-15
    steps:
      - uses: actions/checkout@v4
      - name: Select Xcode
        run: sudo xcode-select -s /Applications/Xcode_16.2.app
      - name: Run Tests
        run: |
          xcodebuild test \
            -scheme MyApp \
            -destination 'platform=iOS Simulator,name=iPhone 16,OS=18.2' \
            -resultBundlePath TestResults.xcresult \
            CODE_SIGN_IDENTITY="" \
            CODE_SIGNING_REQUIRED=NO

Common Testing Mistakes to Avoid

Testing implementation details. If you test that a private method was called, your test breaks on refactors. Test the public interface: given input X, what is the output or side effect?
Skipping error paths. For every success test, write at least one failure test. Bugs hide in error handling.
Shared mutable state between tests. Always create fresh mocks in setUp(). Tests that depend on execution order are worse than no tests.
Async tests without awaiting. A test that does not await an async call passes trivially — assertions run before the work completes.
Too many UI tests. If your suite takes 20 minutes, developers stop running it. Keep the majority as fast unit tests.
Ignoring flaky tests. A flaky test teaches your team to ignore failures. Fix it or delete it.

Bringing It All Together

Testing is not separate from building features — it is part of building features. When you write a ViewModel with protocol-based DI, you simultaneously make it testable and flexible. When you test an error path, you verify users see a helpful message instead of a crash.

Start small. Test one ViewModel. Add a snapshot test for your most complex screen. Set up CI so tests run on every pull request. Within a month, you will wonder how you shipped without them.

If you want a project where this is already wired up — @Observable ViewModels with protocol-based dependency injection, clean MVVM that makes testing straightforward, and a test target with mock services ready to go — check out The Swift Kit. It ships with the architecture from this guide and our MVVM architecture guide built in from day one. See the features page for the full breakdown, or head to pricing and start building on a tested, production-ready foundation.