UI Testing in SwiftUI

Four lines of code above, each one with its meaning and importance. Let’s see them one by one:

1. The first one initializes a XCUIApplication object. That’s probably the most important object when talking about testing for two reasons; firstly, we are going to access all UI elements through that. Secondly, we will use it in order to launch an app instance and run UI tests.
2. The second line launches the app instance.
3. In the third line we’re accessing all static tests in the running app instance. We’re asking for the one having the “Welcome!” content. The returned value is a XCUIElement object assigned to the welcome constant.
4. When creating tests, we actually make assertions regarding the underlying element. We claim here that the Text view with the content specified in the previous line exists indeed, and that the above assertion will make the test pass successfully. There are more methods like XCTAssert() with different purposes; i.e. to check for nil values, equality, true or false values, and so on, some of which we’ll use in this post.

To run the test, first select either a target simulator or a device. Then, either click on the rhombus icon next to the test method’s name, or open the Test navigator, expand the UITestingDemoUITests group and move the mouse over the testWelcome() test; then click on the button that will appear.

Wait for a few seconds until the test is finished. In the meantime, you will see that an instance of the app is launched in the selected simulator or device, and then it terminates. At that moment you’ll also see the test results; a green checkmark on success, a red x-mark on failure. If you followed everything step by step so far, then your first test should be successful:

To make the test fail and see that case too, modify the requested static text. Simply remove the exclamation mark so it becomes like this:

let welcome = app.staticTexts["Welcome"]

Run the test again, and this time you’ll see it becoming red. It failed because no static text with the given value was found, so the assertion resulted to false.

In the above test we accessed the Text view using the contained text value as a subscript to the staticTexts array. However, that is the only Text view existing in the app right now. In such a case, we can get it like so:

let welcome = app.staticTexts.element

The above works for all kinds of UI elements, and we’ll see that later as well.

If we run the test now, it will succeed once again. However, this time we can’t really tell if the Text view’s content is “Welcome!”, or it has changed to something else. We knew that previously, because the only way to get a successful test result was by providing the correct text value in the staticTexts array.

In order to check the text we will add another assert method to the test:

XCTAssertEqual(welcome.label, "Welcome!")

XCTAssertEqual() asserts that the two values given as arguments are equal. That label property above is the accessibility label of the Text view, which by default is the same to its content.

After the above two changes the test now is this:

func testWelcome() throws {
let app = XCUIApplication()
app.launch()

let welcome = app.staticTexts.element

XCTAssert(welcome.exists)
XCTAssertEqual(welcome.label, "Welcome!")
}

If both assertions are true, the test will pass. If you go back to ContentView.swift and change the “Welcome!” text to something else, then the two values in the second assertion will not be equal the test will fail.

Testing The Login Button

Let’s write one more test to verify the login button’s existence:

func testLoginButton() throws {
let app = XCUIApplication()
app.launch()

let login = app.buttons["Login"]

XCTAssert(login.exists)
}

These are necessary in order to run an app instance, and here we’ll do a couple of changes in order to avoid repeating them on every single test.

The first one is to declare an app property in the UITestingDemoUITests class. It will be globally accessible by all tests in the class that way:

class UITestDemoUITests: XCTestCase {
let app = XCUIApplication()

...
}

There are three properties marked with the @Published property wrapper. The first one indicates whether a user is logged in or not, and the other two are string properties that will be keeping the username and password that will be typed in the login form.

There is also a login() method; a fake mechanism to mimic a login process. It returns true if the username and password match to the values shown above, false otherwise. On success, it clears out the password value, and changes the isLoggedIn value to true.

We want an instance of the User class to be available throughout the app, therefore we have to append it to the SwiftUI views’ environment. In order to do that, we have to create a User instance in the UITestingDemoApp structure of the app, in the UITestingDemoApp.swift file:

@main
struct UITestingDemoApp: App {
var user = User()

var body: some Scene {
...
}
}

We can now pass the user property in the views environment:

@main
struct UITestDemoApp: App {
var user = User()

var body: some Scene {
WindowGroup {
ContentView()
.environmentObject(user)
}
}
}

Time to turn to the login form. It will be parted by the following:

• A text field to type in a username.
• A secure text field to type in a password.
• A login button to perform the (fake) login.
• A dismiss button to cancel the login process.

The two text fields with the login button will embedded in a Form view. All together will be the content of a navigation view. The dismiss button will be a bar button to the navigation bar.

We are going to implement that login form in a new SwiftUI file, but we’ll present it modally in a sheet later when the login button gets tapped. That said, press once again the Cmd+N keys, and this time create a new SwiftUI file. Name it LoginView.swift.

The first thing we’ll do in that view, is to declare the following environment object property so we can access the User instance in the environment:

struct LoginView: View {
@EnvironmentObject private var user: User

var body: some View {
...
}
}

In addition, we’ll also declare the next environment property so we can dismiss the sheet later:

See the tap() method? It will trigger a tap gesture as if we were to tap with the finger. All real gestures have similar matching methods to call if necessary, such as doubleTap(), swipeUp(), swipeDown(), pinch(withScale:velocity:), and more.

Next, we’ll get the “Login” title of the navigation bar as a static text through the app property:

func testLoginFormAppearance() throws {
...

let loginNavBarTitle = app.staticTexts["Login"]
}

There’s nothing new to explain here. In fact, we could have skipped that line and use the app.staticTexts["Login"] directly next in the following expression, but it’s more clear to keep it that way.

The second new thing we’re going to meet, is how to expect for a UI element to become available after a specific period of time. In that case, that element is the loginNavBarTitle above. For the sake of the example, we will wait its appearance for 0.5 seconds. If that won’t happen, then our test will fail:

Here’s the full test method’s implementation:

func testLoginFormAppearance() throws {
app.buttons["loginButton"].tap()
let loginNavBarTitle = app.staticTexts["Login"]
XCTAssert(loginNavBarTitle.waitForExistence(timeout: 0.5))
}

Run the test and watch; the login button will be tapped automatically, and when the sheet will appear, the test will pass successful.

Testing For All Elements In Login Form

The previous test actually verifies that the sheet will appear by checking if a static text with the “Login” content will appear after a small period of time. However, it doesn’t tell us if the navigation bar is there, or the textfields and the buttons have been added to the form.

To cover all that, we’ll create the following new test:

func testLoginForm() throws {
app.buttons["Login"].tap()

let navBar = app.navigationBars.element
XCTAssert(navBar.exists)

let username = app.textFields["Username"]
XCTAssert(username.exists)

let password = app.secureTextFields["Password"]
XCTAssert(password.exists)

let login = app.buttons["loginNow"]
XCTAssert(login.exists)
XCTAssertEqual(login.label, "Login")

let dismiss = app.buttons["Dismiss"]
XCTAssert(dismiss.exists)
}

Based on what we have seen so far, it’s easy to understand what the code in the above snippet does. See that for each kind of UI element we are quering the respective collection. Also, regarding the login button, we are making an additional assertion about the label of the button.

You may run the test and see if it will finish successfully or not. To get a better understanding on all the above, feel free to open the LoginView.swift file and change any of the values used in the checks.

Testing The Dismiss Button

Previously we added a bar button to dismiss the sheet, and already added the necessary code that will make that happen. However, that’s an untested functionality, so here we are going to focus on that.

We already met the tap() method that performs a tap gesture programmatically. We’ll use it here once again with the dismiss button. But what are we going to test exactly?

That’s the interesting and new thing in this test; with the help of another XCTAssert method, we’ll make sure that the dismiss button is not present anymore after a specific period of time has elapsed.

Here’s the new test:

func testLoginDismiss() throws {
app.buttons["Login"].tap()
let dismiss = app.buttons["Dismiss"]
dismiss.tap()
XCTAssertFalse(dismiss.waitForExistence(timeout: 0.5))
}

See that we start by triggering a tap gesture initially so we present the sheet. Then we access the dismiss button using the accessibility identifier we set to it, and then we perform a tap gesture on it in order to force the sheet to go away.

The XCTAssertFalse() asserts that the dismiss button won’t exist after 0.5 seconds. If the dismiss button is still there after that time frame, then the test will fail, and that’s an indication that there is something wrong with the button’s implementation.

Testing Username And Password

The next two tests that we are going to write in this part have little practical, but significant educational value. Therefore, it worths having a quick look at them.

In the test that we’ll implement now, we are going to meet a quite specific aspect of UI testing; how to programmatically type text in a text field.

Let’s get to the code first:

func testUsername() throws {
app.buttons["Login"].tap()

let username = app.textFields["Username"]
username.tap()
username.typeText("test")

XCTAssertNotEqual(username.value as! String, "")
}

Focusing on the three lines in the middle of the snippet, firstly we access the username text field using its label. However, given that this is the only text field in the app, we could have used the element property in the textFields collection (app.textFields.element) to do the same.

Next, we make a tap gesture on it, so it becomes the first responder and also make the keyboard appear.

Finally, with the typeText() method we simulate a typing process. We use this method when it’s necessary to test text typing, passing as argument the text value.

In the last line of the test method we assert that the value of the username text field is not equal to the empty string, and we verify that way that the text was really typed in. The value property of the username text field is of Any type, so casting to string is necessary.

In order to test the password entry we can do pretty much the same stuff as above. However, I’ll show you an alternative way to provide text input, as it might be useful sometimes. You can use this one instead of the typeText() method if you notice that the latter fails to enter text properly.

Let’s see the test implementation:

func testPassword() throws {
app.buttons["Login"].tap()

app.secureTextFields.element.tap()
app.keys["p"].tap()
app.keys["a"].tap()
app.keys["s"].tap()
app.keys["s"].tap()
app.keyboards.buttons["Return"].tap()

XCTAssertNotEqual(app.secureTextFields.element.value as! String, "")
}

Once again we tap on the secure text field right after the sheet has been presented, so it becomes the first responder. However, instead of providing the full text we want to type in this time, we simulate taps on the keyboard keys one by one. See that we query the proper key using its text representation to the keys collection first, and then we call the tap() method. We do that as many times as the characters in the string are.

The last tap above demonstrates how to simulate that gesture on the Return key.

Similarly to the previous test, the last line in this one too verifies that the text given to the password is not empty.

Important Note: If you are testing on simulator, then make sure that the keyboard is actually showing up when the secure text field becomes the first responder. If not, then toggle its appearance by pressing Cmd+K after having selected the simulator. If you avoid doing so, the above test will fail.

Testing Login

Time to put everything together and test the login process. In this example we are going to present the sheet, programmatically type values in the username and password fields, and eventually tap on the login button in the sheet. What we expect to see in this test is the sheet being dismissed.

All techniques used in this test have already been presented and explained, so here it is:

func testLogin() throws {
app.buttons["Login"].tap()

app.textFields.element.tap()
app.textFields.element.typeText("test")

app.secureTextFields.element.tap()
app.secureTextFields.element.typeText("pass")
app.keyboards.buttons["Return"].tap()

let loginButton = app.buttons["loginNow"]
loginButton.tap()

XCTAssertFalse(loginButton.waitForExistence(timeout: 0.5))
}

Describing in fast forward speed what goes on here:

1. A tap gesture is performed on the login button in the content view in order to present the sheet with the login form.
2. A tap gesture is performed on the username text field.
3. The “test” value is typed in automatically.
4. A tap gesture is performed on the password textfield.
5. The “pass” value is typed in programmatically.
6. A tap on the Return button of the keyboard happens programmatically so the keyboard gets dismissed.
7. The login button in the sheet is accessed using its accessibility identifier.
8. A tap gesture is performed on that login button.
9. The assertion that the login button in the sheet won’t exist after 0.5 seconds is made.

You can run the test and see the full login process being simulated and tested.

Testing Failed Login

The previous test is useful to verify the successful login process. However, what if the login fails? What if either the username or the password has not been provided, or they have wrong values?

To test this scenario, we will add an alert that will be presented to the user saying that the login has failed. In fact, demonstrating how to deal with alerts and interacting with them through a UI test is what I aim to achieve in this part.

Before we write a new test, it’s necessary to make a couple of additions to the LoginView.swift file, so click to open it in the Project navigator.

Start by adding the following view modifier to the NavigationView in order to show an alert:

NavigationView {
...
}
.alert(isPresented: $showAlert) {
Alert(title: Text("Login Failed"),
message: Text("Either username or password is missing, or they are wrong."),
dismissButton: Alert.Button.default(Text("OK"), action: {
showAlert = false
}))
}

The presented state of the alert is determined by the showAlert binding value, where showAlert is a state property that we have to declare to the LoginView struct:

struct SignInView: View {
...

@State private var showAlert = false

var body: some View {
...
}
}

Finally, it’s also necessary to update the login button’s action closure, and make the showAlert true when the login fails:

if user.login() {
...
} else {
showAlert = true
}

Time to write a new test in the UITestingDemoUITests.swift file. In order to cause the alert’s appearance, we will simply skip providing any values to the text fields. We’ll just trigger a tap gesture to the login button of the sheet.

The next and most interesting part of the test is to verify that the alert has been presented. For that, we’ll assert that the alert will exist within a few moments, and if not, the test will fail.

But we won’t stop there; we’ll interact with the alert and we’ll dismiss it by tapping programmatically on its OK button. After that, we’ll assert once again that the alert does not exist.

All that sounds more complicated than what it actually is, so here is the new test:

func testFailedLoginAlert() throws {
app.buttons["Login"].tap()
app.buttons["loginNow"].tap()

XCTAssert(app.alerts.element.waitForExistence(timeout: 0.5))

app.alerts.element.buttons["OK"].tap()
XCTAssertFalse(app.alerts.element.exists)
}

If you run the test, you should see this:

with this:

Text(!user.isLoggedIn ? "Welcome!" : "Welcome \(user.username)!")

A similar change must take place in the login button’s label, but it’s not just that. The action that the button will trigger now also depends on the isLoggedIn value. So, replace the current button’s implementation:

Button(action: {
showLogin = true
}, label: {
Text("Login")
})

with the following:

Button(action: {
if !user.isLoggedIn {
showLogin = true
} else {
user.logout()
} 
}, label: {
Text(!user.isLoggedIn ? "Login" : "Logout")
})

Notice that in case the user is logged in, the button changes to “Logout”. But more importantly, it triggers the user’s logout by calling the logout() method through the user object. This method does not exist yet; to add it simply switch to the User.swift file and append the following in the User class:

class User: ObservableObject {
...

func logout() {
isLoggedIn = false
username = ""
}
}

Time to test!

Testing The Welcome And Login Button Label

Back to the UITestingDemoUITests.swift file, where we’ll begin by implementing a custom method. In its body we’ll include all those steps that are necessary to perform a succesful login operation. We do that because we’ll need those steps repeateadly in quite a few tests, so let’s group them together in order to save time and space.

Here is the login() method:

func login() throws {
app.buttons["Login"].tap()

app.textFields.element.tap()
app.textFields.element.typeText("test")

app.secureTextFields.element.tap()
app.secureTextFields.element.typeText("pass")
app.keyboards.buttons["Return"].tap()

app.buttons["loginNow"].tap()
}

Adding Fake Settings For Logged In Users

In addition to what we have already done, here we are going to add a form with a few fake settings. This will give us the chance to test a few more UI elements. In particular, the goal in this last part of the tutorial is to see how to test and update the value a segmented control, a slider, and a wheel picker.

Of course, it’s necessary to add the missing implementation that will include those elements in the app before we create any tests. To get started, open the User.swift file, and append the next three properties to the User class:

class User: ObservableObject {
...

@Published var colorTheme = 0
@Published var textSize: Double = 14
@Published var font = "Arial"

...
}

The settings we are going to present are supposed to regard preferences about:

• color theme,
• text size,
• font

We are going to use the binding values of the above properties in the UI elements that we’ll test. The matching between settings and views will go as follows:

• For the color theme we’ll add a segmented control.
• For the text size we’ll add a slider.
• For the font we’ll add a wheel picker.

Let’s go now to the ContentView.swift file. In the VStack and after all the current implementation add the next lines:

VStack {
...

if user.isLoggedIn {
Form {
Section {
VStack {
Text("Color Theme")
Picker("", selection: $user.colorTheme) {
Text("Light").tag(0)
Text("Dark").tag(1)
}
.pickerStyle(SegmentedPickerStyle())
.accessibilityIdentifier("colorTheme")
}
}

Section {
HStack {
Text("Text Size")
Slider(value: $user.textSize, in: 1...100)
.accessibilityIdentifier("slider")
}
}

Section {
VStack {
Text("Font")
Picker("", selection: $user.font) {
Text("Arial").tag("Arial")
Text("Avenir Next").tag("Avenir Next")
Text("Noteworthy").tag("Noteworthy")
Text("Futura").tag("Futura")
}
.pickerStyle(WheelPickerStyle())
.accessibilityIdentifier("fontPicker")
}
}
}
}
}

It’s necessary to check first if the user is logged in or not, and if so, we are adding a Form view. There are three sections in it:

1. The first one regards the color scheme and presents a picker using the segmented style.
2. The second contains a slider to change text size preferences. For simplicity, slider values range from 1 to 100.
3. The last section contains a picker with the wheel style, presenting a small variety of fonts to choose from. Notice that the font names are also used as values to the tag() modifier.

If you want, you can create your own tests to verify that the form is appearing only when the user is logged in, and not otherwise. I’m not going to show that here, as we’ve already implemented tests like that. Also, I’m not going to check the values of the Text views in the new, additional code above. We’ll focus on the segmented control, slider and wheel picker only.

Testing The Segmented Control

Go back to the UITestingDemoUITests.swift file, where we are going to write the next test. This one will regard the segmented control that presents the available fake color theme options.

Similarly to what we did with all the last few tests we created, we’ll start by performing all login steps here too. Then, we’ll proceed like so:

• We’ll access the segmented control using its accessibility identifier, and we’ll assert that it exists.
• After that we’ll assert that the currently selected value is the one with the “Light” title.
• Then we’ll switch to “Dark” value.
• Finally, we’ll assert once again that the selected value is the “Dark” one.

Here’s all that in code:

func testColorTheme() throws {
try login()

let colorTheme = app.segmentedControls["colorTheme"]
XCTAssert(colorTheme.exists)
XCTAssert(colorTheme.buttons["Light"].isSelected)

colorTheme.buttons["Dark"].tap()
XCTAssert(colorTheme.buttons["Dark"].isSelected)
}

First of all, notice that we access the segmented control by quering the segmentedControls collection, no matter that in SwiftUI we create it as a picker.

On top of that, it’s quite interesting how we get the selected segment; in fact, a segment is a button that we access using its displayable label, and then with the isSelected property we determine if it’s selected or not.

To change the current selection, all we need is to perform a tap gesture on the button with the desired label. The last assert confirms that the selected segment has changed indeed.

Testing The Slider

In the next test that we’ll implement, we will meet how to change the value of a slider from a UI test. There is a specific method available to that, and once we do so, I’ll show you how to assert the new value of the slider.

Right next you can see the test implementation:

func testTextSize() throws {
try login()

let textSize = app.sliders["slider"]
XCTAssert(textSize.exists)

textSize.adjust(toNormalizedSliderPosition: 0.75)
XCTAssertGreaterThanOrEqual(textSize.value as! String, "0.7")
}