Подключение внешнего фреймворка к цели модульного тестирования пользовательского интерфейса, iOS

Итак, у меня уже есть существующий проект, и я пытаюсь создать несколько тестов пользовательского интерфейса, используя этот новый модный пакет тестирования пользовательского интерфейса, предоставляемый Apple. Проблема в том, что тестовая цель не имеет доступа к какой-либо внешней структуре (и мне нужно выполнить некоторую настройку с одной из них). Добавление фреймворка на этапах сборки и копирование пути поиска фреймворка от основной цели ничего не дает.

После дня просмотра я обнаружил только одну вещь, которая «делает вещи отчасти другими». Настроив Bundle Loader и Test Host на $ (BUILT_PRODUCTS_DIR) /App.app/App, я все еще не мог импортировать внешние фреймворки в test.m, но я мог импортировать классы, которые делают это для них себя. И все было бы хорошо и красиво, если бы это не сломало кое-что. Установив Bundle и Host сейчас, мой тест пользовательского интерфейса не может выполнить метод запуска:

[[[XCUIApplication alloc] init] launch];

Он вылетает с ошибкой: Ошибка утверждения: ошибка тестирования пользовательского интерфейса - состояние приложения все еще не прекращено.

В конце концов, я мог бы удалить метод запуска из настройки и запускать каждый тест вручную, поэтому он перезапускает приложение каждый раз перед выполнением, но это решение кажется неправильным (особенно для некоторых более крупных проектов). Кто-нибудь знает, как правильно решить эту проблему?


person BigSzu    schedule 25.06.2015    source источник
comment
Это также применимо к приложениям OS X, и всем разработчикам Apple необходим ответ, чтобы воспользоваться этой функцией в El Capitan.   -  person Claus Jørgensen    schedule 30.07.2015


Ответы (1)


Для этого я добавил переменную среды в XCUIApplication, чтобы указать, что тесты пользовательского интерфейса выполняются. Затем я выполняю предпроцессорную проверку #DEBUG в основной части приложения, а затем проверяю, установлена ​​ли переменная среды test; если да, выполните необходимые шаги для тестов пользовательского интерфейса.

По сути, это позволит вам настроить ваше приложение так, как вам нужно для запуска тестов пользовательского интерфейса. Это также означает, что проверка препроцессора полностью удалит этот установочный код для сборки выпуска.

person Harry    schedule 03.08.2015
comment
Это сработает, если вы создаете небольшое хобби-приложение без значительного количества данных, которые можно было бы подделать. Это невыполнимый подход для тестирования приложений в реальном мире, подумайте о тестировании в стиле Facebook / Instagram, но с фальшивыми данными. - person Claus Jørgensen; 03.08.2015
comment
Зависит от того, что вы подразумеваете под фальшивыми данными. Таким образом вы можете легко загрузить предварительно созданную базу данных sqlite. Конечно, вы можете не получить полного эффекта от тестирования пользовательского интерфейса, если вы все фальсифицируете. - person Harry; 03.08.2015
comment
Если вы воображаете, что программные приложения просто представляют кэшированные данные, это будет трудно объяснить. Подумайте о входе в систему, интерактивных чатах, звонках, видео, аудио, открытии / закрытии вкладок, окнах, изменении настроек, цветов, доступности, озвучивании и т. Д. И каждый тест написан изолированно, что требует сброса доступные и ожидаемые данные в каждом тесте. Вот почему нам нужен доступ к тем же данным, что и для модульных тестов, иначе фреймворк бесполезен по сравнению с KIF на iOS (и ничего на OS X). - person Claus Jørgensen; 04.08.2015