Bird
Raised Fist0
iOS Swiftmobile~7 mins

UI testing with XCUITest in iOS Swift

Choose your learning style10 modes available
Introduction

UI testing helps you check if your app looks and works right by simulating user actions automatically.

You want to make sure buttons and links respond correctly.
You need to test navigation between screens without tapping manually.
You want to catch bugs before users find them.
You want to check if text and images appear as expected.
You want to repeat tests easily after app updates.
Syntax
iOS Swift
import XCTest

class MyAppUITests: XCTestCase {
  let app = XCUIApplication()

  override func setUp() {
    super.setUp()
    continueAfterFailure = false
    app.launch()
  }

  func testExample() {
    app.buttons["MyButton"].tap()
    XCTAssertTrue(app.staticTexts["Welcome"].exists)
  }
}
Use XCUIApplication() to control your app in tests.
Use accessibility identifiers to find UI elements easily.
Examples
Taps a button labeled "Login".
iOS Swift
app.buttons["Login"].tap()
Checks if a text "Hello" is visible on screen.
iOS Swift
XCTAssertTrue(app.staticTexts["Hello"].exists)
Taps the username field and types text into it.
iOS Swift
app.textFields["Username"].tap()
app.textFields["Username"].typeText("user123")
Sample App

This test launches the app, taps a button named "ShowMessage", and checks if the label "Hello, World!" appears.

iOS Swift
import XCTest

class SimpleUITest: XCTestCase {
  let app = XCUIApplication()

  override func setUp() {
    super.setUp()
    continueAfterFailure = false
    app.launch()
  }

  func testTapButtonShowsLabel() {
    app.buttons["ShowMessage"].tap()
    XCTAssertTrue(app.staticTexts["Hello, World!"].exists)
  }
}
OutputSuccess
Important Notes

Always set accessibility identifiers in your app for UI elements to make testing easier.

Use continueAfterFailure = false to stop tests immediately when something fails.

Run UI tests on a simulator or real device to see how your app behaves.

Summary

UI testing with XCUITest lets you automate tapping, typing, and checking UI elements.

Use accessibility identifiers to find buttons, labels, and fields in tests.

Write tests to catch UI problems early and save time on manual testing.

Practice

(1/5)
1. What is the main purpose of using XCUITest in iOS app development?
easy
A. To automate user interface testing by simulating user actions
B. To write backend server code for the app
C. To design app icons and graphics
D. To manage app database connections

Solution

  1. Step 1: Understand XCUITest's role

    XCUITest is a framework designed to automate UI testing by simulating taps, typing, and other user interactions.
  2. Step 2: Eliminate unrelated options

    The options for designing app icons/graphics, writing backend server code, and managing database connections are incorrect, as they are not related to XCUITest's purpose of UI testing.
  3. Final Answer:

    To automate user interface testing by simulating user actions -> Option A
  4. Quick Check:

    UI testing = automate user actions [OK]
Hint: XCUITest automates what users do on the screen [OK]
Common Mistakes:
  • Confusing UI testing with backend development
  • Thinking XCUITest is for design or graphics
  • Assuming it manages databases
2. Which of the following is the correct way to launch the app in an XCUITest case?
easy
A. let app = UIApplication() app.start()
B. let app = XCUIApplication() app.launch()
C. let app = XCUIElement() app.open()
D. let app = XCUIApplication() app.run()

Solution

  1. Step 1: Recall correct class and method

    In XCUITest, XCUIApplication() creates the app instance, and launch() starts it.
  2. Step 2: Check method names and classes

    UIApplication and XCUIElement are incorrect for launching tests; start() and run() are not valid methods here.
  3. Final Answer:

    let app = XCUIApplication()\napp.launch() -> Option B
  4. Quick Check:

    Use XCUIApplication and launch() [OK]
Hint: XCUIApplication().launch() always starts the app in tests [OK]
Common Mistakes:
  • Using UIApplication instead of XCUIApplication
  • Calling non-existent methods like start() or run()
  • Confusing XCUIElement with the app instance
3. Given the following XCUITest code snippet, what will be the result?
let app = XCUIApplication()
app.launch()
let button = app.buttons["submitButton"]
if button.exists {
    button.tap()
    print("Tapped")
} else {
    print("Button not found")
}
medium
A. Always prints "Button not found" regardless of button presence
B. Prints "Tapped" even if the button does not exist
C. Causes a compile-time error due to incorrect syntax
D. Prints "Tapped" if the button with accessibility identifier "submitButton" exists

Solution

  1. Step 1: Analyze button existence check

    The code checks if the button with identifier "submitButton" exists using button.exists.
  2. Step 2: Understand conditional behavior

    If the button exists, it taps and prints "Tapped"; otherwise, it prints "Button not found".
  3. Final Answer:

    Prints "Tapped" if the button with accessibility identifier "submitButton" exists -> Option D
  4. Quick Check:

    Button exists? Tap and print "Tapped" [OK]
Hint: Check .exists before tap to avoid errors [OK]
Common Mistakes:
  • Assuming print always shows "Button not found"
  • Thinking code has syntax errors
  • Ignoring the existence check before tap
4. Identify the error in this XCUITest code snippet:
let app = XCUIApplication()
app.launch()
let textField = app.textFields["username"]
textField.typeText("user123")
app.buttons["login"].tap()
medium
A. Incorrect app launch method used
B. Using typeText instead of setText method
C. Missing check if textField exists before typing
D. Buttons cannot be tapped in XCUITest

Solution

  1. Step 1: Review element existence checks

    The code types text into a text field without verifying if it exists, which can cause test failures.
  2. Step 2: Confirm other method usages

    typeText is the correct method; app.launch() is correct; buttons can be tapped in XCUITest.
  3. Final Answer:

    Missing check if textField exists before typing -> Option C
  4. Quick Check:

    Always check element exists before interaction [OK]
Hint: Check .exists before typing or tapping [OK]
Common Mistakes:
  • Skipping existence checks causing crashes
  • Confusing typeText with non-existent methods
  • Thinking buttons can't be tapped in tests
5. You want to write an XCUITest that verifies a label updates after tapping a button. Which approach correctly waits for the label to change text before asserting?
let app = XCUIApplication()
app.launch()
let button = app.buttons["updateButton"]
let label = app.staticTexts["statusLabel"]
button.tap()
// What code waits for label text to change to "Done"?
hard
A. let exists = NSPredicate(format: "label == 'Done'") expectation(for: exists, evaluatedWith: label, handler: nil) waitForExpectations(timeout: 5, handler: nil)
B. sleep(5) assert(label.label == "Done")
C. while label.label != "Done" {} assert(true)
D. assert(label.label == "Done") immediately after tap

Solution

  1. Step 1: Understand waiting for UI changes

    Using NSPredicate with expectation waits properly for the label's text to become "Done" within timeout.
  2. Step 2: Evaluate other options

    sleep() is unreliable; busy-wait loop blocks test; immediate assert may fail if UI hasn't updated yet.
  3. Final Answer:

    let exists = NSPredicate(format: "label == 'Done'")\nexpectation(for: exists, evaluatedWith: label, handler: nil)\nwaitForExpectations(timeout: 5, handler: nil) -> Option A
  4. Quick Check:

    Use expectations to wait for UI updates [OK]
Hint: Use XCTest expectations to wait for UI changes [OK]
Common Mistakes:
  • Using sleep instead of expectations
  • Busy-wait loops freezing tests
  • Asserting UI state immediately after action
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard