TestableView

TestableView improves SwiftUI unit testing by cutting through the clutter of boilerplate code, letting you zero in on what matters: your test's intent.

Contents

• Boilerplate example
• Adding it to your project
  • Production code
  • Test code
• Use it in your test
• Testing with Environment
• Acknowledgements
• About the Author

Boilerplate example

When using ViewInspector to unit test a SwiftUI View that uses @State or @Environment, the simplest approach is to add a hook called on didAppear. The test then:

• wraps a closure into that hook,
• creates an XCTestExpectation so the test can wait for the hook,
• mounts the View, and
• waits for the closure to run.

@MainActor
func test_incrementOnce_withBoilerplate() throws {
    var sut = ContentView()
    let expectation = sut.on(\.viewInspectorHook) { view in
        try view.find(viewWithAccessibilityIdentifier: "increment").button().tap()
        let count = try view.find(viewWithAccessibilityIdentifier: "count").text().string()
        XCTAssertEqual(count, "1")
    }
    ViewHosting.host(view: sut)
    defer { ViewHosting.expel() }
    wait(for: [expectation], timeout: 0.4)
}

^{snippet source | anchor}

That's a lot of boilerplate, and it makes it harder to scan for the test intent.

XCTestCase+InspectChangingView.swift provides an XCTestCase extension to take care of that boilerplate.

Adding it to your project

The new XCTestCase method relies on a TestableView type to define the hook for ViewInspector. So you need to use one file in your production code, and one file in your test code.

Production code

1. Copy TestableView.swift into your production code. You can also subscribe to my blog, install the custom code snippets, and expand “testableview” into a new file.
2. Redefine your View as a TestableView. Xcode will tell you how to define your hook property.
3. Make sure to call the hook at the end of your view:

.onAppear { self.viewInspectorHook?(self) }

^{snippet source | anchor}

Test code

1. Copy XCTestCase+InspectChangingView.swift into your test code.
2. Change the YourModule placeholder so it does an @testable import from the module that defines TestableView.

Use it in your test

Now our test can call inspectChangingView(_:action:) like this:

@MainActor
func test_incrementOnce_withTestableView() throws {
    var sut = ContentView()

    inspectChangingView(&sut) { view in
        try view.find(viewWithAccessibilityIdentifier: "increment").button().tap()

        let count = try view.find(viewWithAccessibilityIdentifier: "count").text().string()
        XCTAssertEqual(count, "1")
    }
}

^{snippet source | anchor}

That's much simpler, hiding the boilerplate that isn't part of the test-specific intent. Now we have an expressive SwiftUI unit test!

Testing with Environment

The previous example was one of @State. What about @Environment? For that, there's another helper inspectView(_:environment:value:):

@MainActor
func test_greets_with_injected_username() throws {
    var sut = GreetingView()

    inspectView(&sut, environment: \.username, value: "Alice") { view in
        let greeting = try view.find(viewWithAccessibilityIdentifier: "greeting").text().string()

        XCTAssertEqual(greeting, "Hello, Alice!")
    }
}

^{snippet source | anchor}

Acknowledgements

• Alexey Naumov for creating ViewInspector
• “The regulars” on my Twitch stream for refactoring with me
• Joe Cursio for suggesting a better name, inspectChangingView

About the Author

Jon Reid is the author of iOS Unit Testing by Example.
Find more at Quality Coding.