iOS

SwiftUI ViewInspector: Unit Testing SwiftUI Views Without UI Automation

HelpMeTest

HelpMeTest

— 4 min read
SwiftUI ViewInspector: Unit Testing SwiftUI Views Without UI Automation

XCUITest runs your app in a simulator — it's slow, flaky, and gives no introspection into SwiftUI internals. ViewInspector lets you unit test SwiftUI views directly: inspect the view hierarchy, find subviews by type, trigger bindings, simulate button taps, and assert on text values — all without launching a simulator. This guide covers setup, common patterns, and how to test stateful views.

Why XCUITest Isn't Enough for SwiftUI

XCUITest is a black-box tool. It sees your app through accessibility identifiers, which means:

  • You can't inspect whether a Text view has the right font or color
  • You can't test conditional rendering without asserting on visible strings
  • Tests take 30–60 seconds to launch the simulator
  • Any view-level logic has to be inferred from observable output

For unit-level confidence — "does this view render the right subviews given this state?" — you need something that can introspect SwiftUI's view tree at the type level.

ViewInspector (github.com/nalexn/ViewInspector) is a third-party library that makes SwiftUI's view body inspectable from test code.

Installation

Add ViewInspector to your test target via Swift Package Manager:

// Package.swift (or Xcode SPM integration)
.package(url: "https://github.com/nalexn/ViewInspector.git", from: "0.9.0")

// In your test target dependencies:
.testTarget(
    name: "MyAppTests",
    dependencies: [
        "MyApp",
        "ViewInspector"
    ]
)

ViewInspector works with Swift 5.7+ and iOS 14+. It does not require any changes to your production code in most cases.

Making Views Inspectable

For simple View structs with no internal state, you can inspect them directly:

import SwiftUI

struct GreetingView: View {
    let name: String

    var body: some View {
        VStack {
            Text("Hello, \(name)!")
                .font(.title)
            Image(systemName: "hand.wave")
        }
    }
}

Test it:

import XCTest
import ViewInspector
@testable import MyApp

final class GreetingViewTests: XCTestCase {
    func testGreetingText() throws {
        let view = GreetingView(name: "World")
        let text = try view.inspect().vStack().text(0).string()
        XCTAssertEqual(text, "Hello, World!")
    }

    func testContainsWaveImage() throws {
        let view = GreetingView(name: "World")
        let image = try view.inspect().vStack().image(1)
        XCTAssertEqual(try image.actualImage(), Image(systemName: "hand.wave"))
    }
}

The .inspect() call returns an InspectableView hierarchy you can traverse with type-safe accessors.

Testing Views with @State

For views that use @State, ViewInspector needs a hook to receive async callbacks when state changes. You conform your view to Inspectable:

import SwiftUI
import ViewInspector

struct CounterView: View, Inspectable {
    @State private var count = 0
    internal let didAppear: ((Self) -> Void)?

    init(didAppear: ((Self) -> Void)? = nil) {
        self.didAppear = didAppear
    }

    var body: some View {
        VStack {
            Text("Count: \(count)")
            Button("Increment") { count += 1 }
        }
        .onAppear { didAppear?(self) }
    }
}

Then in your test, use the async inspection pattern:

final class CounterViewTests: XCTestCase {
    func testInitialCount() throws {
        let expectation = XCTestExpectation(description: "View appeared")
        var sut = CounterView(didAppear: { view in
            defer { expectation.fulfill() }
            let text = try? view.inspect().vStack().text(0).string()
            XCTAssertEqual(text, "Count: 0")
        })
        ViewHosting.host(view: sut)
        wait(for: [expectation], timeout: 1.0)
    }

    func testIncrementButton() throws {
        let expectation = XCTestExpectation(description: "Button tapped")
        expectation.expectedFulfillmentCount = 2

        var tapCount = 0
        var sut = CounterView(didAppear: { view in
            tapCount += 1
            if tapCount == 1 {
                // First appearance — tap the button
                try? view.inspect().vStack().button(1).tap()
                expectation.fulfill()
            } else {
                // Second appearance — state has updated
                let text = try? view.inspect().vStack().text(0).string()
                XCTAssertEqual(text, "Count: 1")
                expectation.fulfill()
            }
        })
        ViewHosting.host(view: sut)
        wait(for: [expectation], timeout: 2.0)
    }
}

ViewHosting.host(view:) inserts the view into a real window, enabling onAppear to fire and state mutations to propagate.

Testing Views with @ObservedObject

When your view depends on an ObservableObject, inject it in tests just like production code:

class CartViewModel: ObservableObject {
    @Published var items: [String] = []

    func addItem(_ item: String) {
        items.append(item)
    }
}

struct CartView: View {
    @ObservedObject var viewModel: CartViewModel

    var body: some View {
        List(viewModel.items, id: \.self) { item in
            Text(item)
        }
        .overlay {
            if viewModel.items.isEmpty {
                Text("Your cart is empty")
            }
        }
    }
}

Test:

final class CartViewTests: XCTestCase {
    func testEmptyCartShowsMessage() throws {
        let vm = CartViewModel()
        let view = CartView(viewModel: vm)
        let message = try view.inspect().overlay().text().string()
        XCTAssertEqual(message, "Your cart is empty")
    }

    func testItemsAppearInList() throws {
        let vm = CartViewModel()
        vm.addItem("Apple")
        vm.addItem("Banana")

        let view = CartView(viewModel: vm)
        let list = try view.inspect().list()
        XCTAssertEqual(try list.count(), 2)
        XCTAssertEqual(try list.text(0).string(), "Apple")
        XCTAssertEqual(try list.text(1).string(), "Banana")
    }
}

No didAppear hook needed here because ObservedObject state is injected synchronously before inspection.

Inspecting Conditional Views

ViewInspector handles if/else via .group() or direct type inspection:

struct StatusView: View {
    let isLoggedIn: Bool

    var body: some View {
        if isLoggedIn {
            Text("Welcome back!")
        } else {
            Button("Log In") { }
        }
    }
}
func testLoggedInShowsWelcome() throws {
    let view = StatusView(isLoggedIn: true)
    let text = try view.inspect().text().string()
    XCTAssertEqual(text, "Welcome back!")
}

func testLoggedOutShowsButton() throws {
    let view = StatusView(isLoggedIn: false)
    let label = try view.inspect().button().labelView().text().string()
    XCTAssertEqual(label, "Log In")
}

Testing Modifiers

ViewInspector can traverse view modifiers to assert styling:

struct PrimaryButton: View {
    let title: String

    var body: some View {
        Text(title)
            .padding()
            .background(Color.blue)
            .foregroundColor(.white)
            .cornerRadius(8)
    }
}
func testPrimaryButtonHasBlueBackground() throws {
    let view = PrimaryButton(title: "Submit")
    let bg = try view.inspect().text().background().color()
    XCTAssertEqual(bg, Color.blue)
}

func testPrimaryButtonTitle() throws {
    let view = PrimaryButton(title: "Submit")
    let text = try view.inspect().text().string()
    XCTAssertEqual(text, "Submit")
}

What ViewInspector Can't Do

ViewInspector is a unit-testing tool — it has limits:

  • No pixel rendering. It can't verify visual appearance, layout calculations, or animations.
  • No gesture recognizers. It simulates .onTapGesture callbacks but not swipe gestures or complex touch sequences.
  • No navigation stack state. NavigationLink destination traversal is limited.
  • No async views. Views that show data after an async network call require additional coordination.

For these cases, XCUITest or snapshot testing (via iOSSnapshotTestCase / swift-snapshot-testing) is more appropriate.

Combining ViewInspector with XCTest Best Practices

A practical iOS testing strategy:

Layer Tool Speed What it covers
ViewModel logic XCTest (plain) Very fast Business logic, state transitions
View rendering logic ViewInspector Fast Conditional views, text content, button actions
Visual appearance swift-snapshot-testing Medium Pixel-level regression
End-to-end flows XCUITest Slow Full user journeys

ViewInspector slots into the "view rendering logic" layer — faster than snapshots, more introspective than XCUITest.

Summary

ViewInspector fills the gap between ViewModel unit tests and slow UI automation. Use it to:

  • Assert view hierarchy structure given different state inputs
  • Simulate button taps and verify resulting state changes
  • Test conditional rendering branches deterministically
  • Validate modifier values like colors, fonts, and padding

It won't replace XCUITest for end-to-end flows, but it makes the 80% of view logic that is "given X state, render Y structure" fast to test and easy to maintain.

Read more