UI test fails due to "speed up your typing" tutorial

Sometimes when running UI tests, the tests fail on keyboard input because the "Speed up your typing" keyboard tutorial overlay obscures the keys. This happens randomly, but sometimes repeatedly.

Is there a way to turn this off? Checking for this tutorial before any keyboard input would significantly complicate tests just to check for one edge case...
Post not yet marked as solved Up vote post of Aurelian Down vote post of Aurelian
2.6k views

Replies

Hey Aurelian,

Sorry to hear you're frustrated by this! Is it possible to have you file a Feedback through Feedback Assistant so we can track this? It would be really helpful for you to provide some reproduction steps if you have any as well, including a result bundle from the failing test run with screenshots.

As for a workaround, this is likely happening if you're running your tests on a fresh iOS install if you're running it on device. I'd try to avoid re-imaging devices on every run if you currently are as that can cause these sort of interrupting UIs to appear quite frequently.

That said, we have a session this year I think you'd find really helpful as another solution to your problem is to have a shared UI Interruption Handler your tests reuse. This code would dismiss this overlay. The session is called Handle interruptions and alerts in UI tests.

I hope this helps!

  • As of Xcode 13.3 and testing on an iOS 15.4 simulator. This keyboard onboarding screen that covers the keyboard when it is presented for the first time on every fresh install of iOS (or every time I choose Device > Erase All Content and Settings… from the Simulator app) does not count as an interruption by the XCTest framework and does not trigger a call to the interruption handler closure.

  • Thanks @alobaili @Developer Tools Engineer could you please advise how to escalate this issue? Your answer sounds very helpful but does not solve the original question, which happens to all developers/all fresh runs. Thanks

Add a Comment
Hey, this is happening in CI, which runs our builds in a VM, so we always have a clean environment (with a brand new simulator).

I've actually watched the session on interruptions earlier and am now testing to see if I can make it work.

The session mentions there are built-in interruption monitors for common system dialogs - shouldn't this be added there too? There is nothing for the test to do besides tapping the "Continue" button anyway...

As of Xcode 13.3 and iOS 15.4, the keyboard onboarding screen does not count as an interruption by the XCTest framework and does not trigger a call to the interruption handler closure of addUIInterruptionMonitor(withDescription:handler:).

I created this convenient function that taps a keyboard key while also handling the keyboard onboarding screen. It should minimize the chances of failing a test that interacts with the keyboard.

extension XCUIApplication {
    /// Taps the specified keyboard key while handling the 
    /// keyboard onboarding interruption, if it exists.
    /// - Parameter key: The keyboard key to tap.
    func tapKeyboardKey(_ key: String) {
        let key = self.keyboards.buttons[key]

        if key.isHittable == false {
            // Attempt to find and tap the Continue button
            // of the keyboard onboarding screen.
            self.buttons["Continue"].tap()
        }

        key.tap()
    }
}
  • I find that this workout doesn't work on xcode cloud. Does still work locally.

    We really need a proper solution to this problem from Apple.

Add a Comment

Would be nice if Apple disabled all these along with reminders to set up Siri and the other tutorials/reminders/nags when device is working in developer mode. Or create a separate "interruption-free developer mode".

So I've got anther solution which appears to work on xcode cloud. Basically this solution brings up the spotlight search on the homescreen before launching the first test. This may (or may not) show the 'speed up your typing' tutorial. When your test/app runs - the actual keyboard will show.

class SpringboardHelper {
    private static var keyboardDismissed = false

    /// Call this from the setUp() function of any UI test that deals with the keyboard.
    static func showKeyboardIfNeeded() {
        if !keyboardDismissed {
            let springBoard = XCUIApplication(bundleIdentifier: "com.apple.springboard")
            springBoard.activate()
            springBoard.windows.firstMatch.swipeDown(velocity: .slow)
            springBoard.windows.firstMatch.tap()
            springBoard.windows.firstMatch.swipeUp(velocity: .slow)

            keyboardDismissed = true
        }
    }
}

// THEN in the test....

final class AppUITests: XCTestCase {

    override func setUpWithError() throws {
        SpringboardHelper.showKeyboardIfNeeded()
    }
}

Ive also got a gist that i plan to keep up-to date as necessary:... https://gist.github.com/sushant-here/92e38e0af8770b4c79c5052995c9a484