Тест пользовательского интерфейса завершается с ошибкой, когда он вводит текст в текстовое представление при запуске Xotode-бота
У меня есть следующий тест пользовательского интерфейса XCTest, который печатает текст в текстовом виде.
let textView = app.textViews.elementBoundByIndex(0)
textView.tap()
textView.typeText("Hello world")
При запуске как бот Xcode он отображает следующую ошибку для вызова typeText
.
Утверждение: Ошибка тестирования пользовательского интерфейса - сбой: время ожидания завершения ключевого события
![введите описание изображения здесь]()
Интересно, когда я запускаю его вручную из Xcode на том же компьютере, тест проходит. Этот тест также прошел в боксе Xcode перед обновлением до Xcode 7.1/iOS 9.1. Что может быть источником проблемы?
Вот отдельная демонстрация с тестом UI:
https://github.com/exchangegroup/UITestTextViewDemo
iOS 9.1 Simulator, OS X 10.11.1 (15B42), Xcode 7.1 (7B91b), OS X Server 5.0.15 (15S4033)
Сообщено Apple.
Ответы
Ответ 1
Я нашел решение для своего дела, и я надеюсь, что он вам тоже поможет.
В моих setUp()
и tearDown()
(кажется, лишний я знаю) я положил XCUIApplication().terminate()
. Это гарантирует, что приложение будет завершено перед запуском следующего теста и, похоже, выполнит эту работу.
override func setUp() {
XCUIApplication().terminate()
super.setUp()
continueAfterFailure = false
XCUIApplication().launch()
}
override func tearDown() {
super.tearDown()
XCUIApplication().terminate()
}
Я подал ошибку с Apple, но пока это вызывает у меня ошибку, которую вы видели. Надеюсь, что это поможет!
Ответ 2
Я считаю, что основная проблема заключается в том, что "Connect Hardware Keyboard" включен по умолчанию. Даже если вы отключите его для основного пользователя, пользователь _xcsbuildd по-прежнему использует значение по умолчанию. Я смог решить проблему, добавив к схеме следующее тестовое действие со следующим script:
if [ `defaults read com.apple.iphonesimulator ConnectHardwareKeyboard` -eq 1 ]
then
defaults write com.apple.iphonesimulator ConnectHardwareKeyboard -bool false
killall "Simulator"
fi
![введите описание изображения здесь]()
Ответ 3
Я нашел другое решение, так как предложенный Konnor не работал у меня: у меня было много проблем с использованием UITest на Xcode Bot, и общим симптомом было то, что тестирование на симуляторе занимало гораздо больше времени, чем на локальной машине, поэтому я подумал, что пользователь _xcsbuildd, используемый для запуска тестов, каким-то образом замедлился.
Мое решение просто: просто продвигайте пользователя _xcsbuildd как "обычного" пользователя. Это имеет еще одно преимущество: если вы хотите, чтобы вы могли войти в систему с этим пользователем и увидеть тесты, запускаемые в симуляторе во время интеграции, поэтому его легче отлаживать!
Вот как я это сделал:
sudo dscl . -create /Users/_xcsbuildd UserShell /bin/bash
sudo dscl . -create /Users/_xcsbuildd FirstName Xcode
sudo dscl . -create /Users/_xcsbuildd LastName Server
sudo dscl . -create /Users/_xcsbuildd FullName "Xcode Server"
sudo dscl . -create /Users/_xcsbuildd PrimaryGroupID 20
Затем измените пароль с помощью:
sudo dscl . -passwd /Users/_xcsbuildd
Я не смог заставить пользователя отображаться в окне быстрого входа в систему, так или иначе вы должны увидеть "другого пользователя", где вы можете вставить имя пользователя "_xcsbuildd" и пароль, который вы выбрали
Ответ 4
Я столкнулся с этой проблемой. Я написал тест UI для захвата скриншотов с помощью Snapshot (fastlane), и он отлично работает на симуляторе iPad Air и Pro. Однако на симуляторе iPad Retina или iPad 2 я получаю это сообщение об ошибке, либо запущенном из командной строки, либо непосредственно из Xcode.
Решение в моем случае состояло в том, чтобы добавить некоторые функции sleep() между операторами typeText(), и ошибка исчезла.
Изменить: это только исправление выполняется вручную из Xcode, через командную строку все еще вызывает сбой теста. Я также заметил, что он работает на всех симуляторах для 64-битных устройств, но не на более ранних устройствах.
Изменить 2. Я нашел способ обойти эту проблему с помощью симулятора iOS 9.0 вместо iOS 9.3, как упоминалось в этом ответе: fooobar.com/questions/313290/.... Это кажется хорошим обходным решением, пока оно не будет исправлено в новой версии Xcode.
Ответ 5
Помимо подключения аппаратной клавиатуры, ни одна из этих вещей для меня не работала. Что сделало работу отключением экранной заставки Mac и отображением сна в системных настройках. Мое подозрение в том, что симулятор выполняет странно, когда Mac заблокирован или нет монитора для рисования.
Если эти две настройки отключены, я по-прежнему получаю несколько случайных сбоев теста пользовательского интерфейса. Подключение аппаратных мониторов или совместного использования экрана, поэтому симулятор рисуется на экране где-то, похоже, разрешает их.
Ответ 6
Я использую xcode 8.2.1 и выполняю тесты в версиях ios 9.3. Одним простым взломом является добавление сна в течение 2-5 секунд после нажатия на текстовое поле и перед вводом на него. Хотя это не постоянное решение.
ДРУГОЕ НАДЕЖНОЕ РЕШЕНИЕ
Отмените выбор всех настроек клавиатуры в настройках перед запуском тестов.
"KeyboardAllowPaddle": false,
"KeyboardAssistant": false,
"KeyboardAutocapitalization": false,
"KeyboardAutocorrection": false,
"KeyboardCapsLock": false,
"KeyboardCheckSpelling": false,
"KeyboardPeriodShortcut": false,
"KeyboardPrediction": false,
"KeyboardShowPredictionBar": false