Асинхронное тестирование пользовательского интерфейса в Xcode с Swift
Я пишу приложение, которое делает множество сетевых запросов. Как обычно, они асинхронные, то есть вызов метода запроса возвращается немедленно, а результат доставляется через метод делегата или в закрытии после некоторой задержки. Теперь на экране регистрации я отправил запрос на регистрацию в свой бэкэнд и хочу убедиться, что успешный пользовательский интерфейс отображается после завершения запроса.
Какие есть варианты, чтобы дождаться завершения запроса, проверить успешность пользовательского интерфейса и только после этого оставить тестовый метод?
Также есть ли более умные варианты, чем ожидание завершения запроса?
Заранее спасибо!
2 ответа
Тривиальный подход
Apple реализовала значительные улучшения в Xcode 9 / iOS 11, которые позволяют вам ждать появления элемента пользовательского интерфейса. Вы можете использовать следующий однострочник:
<#yourElement#>.waitForExistence(timeout: 5)
Продвинутый подход
В целом пользовательский интерфейс и модульные тесты (называемые здесь тестами) должны выполняться как можно быстрее, чтобы разработчик мог часто их запускать, и его не смущала необходимость запускать набор медленных тестов несколько раз в день. В некоторых случаях существует вероятность того, что (внутреннее или связанное с безопасностью) приложение получит доступ к API, доступ к которому возможен только из определенных сетей / диапазонов / хостов IP. Кроме того, большинство сервисов CI предлагают довольно плохое оборудование и ограниченную скорость интернет-соединения.
По всем этим причинам рекомендуется выполнять тесты таким образом, чтобы они не выполняли реальных сетевых запросов. Вместо этого они запускаются с поддельными данными, так называемыми приборами. Умный разработчик реализует этот набор тестов таким образом, что источник данных может быть переключен с помощью простого переключателя, такого как логическое свойство. Кроме того, когда переключатель настроен на получение реальных данных бэкэнда, приборы могут автоматически обновляться / записываться с бэкэнда. Таким образом, довольно просто обновить поддельные данные и быстро обнаружить изменения API.
Но главное преимущество этого подхода - скорость. Ваш тест не будет выполнять реальные сетевые запросы, а будет работать с локальными данными, что делает их независимыми от:
- проблемы с сервером
- скорость соединения
- сетевые ограничения
Таким образом, вы можете выполнять свои тесты очень быстро и, следовательно, гораздо чаще, что является хорошим способом написания кода ("Разработка через тестирование").
С другой стороны, вы больше не будете сразу обнаруживать изменения сервера, так как поддельные данные не будут меняться при изменении данных бэкэнда. Но это решается простым обновлением ваших приборов с помощью переключателя, который вы внедрили, потому что вы умный разработчик, который делает эту проблему историей, которую вы можете рассказать своим детям!
Но подождите, я кое-что забыл! Почему это замена тривиального подхода выше - спросите вы? Просто! Поскольку вы используете локальные данные, которые доступны немедленно, вы также можете немедленно вызвать обработчик завершения. Таким образом, нет никакой задержки между выполнением запроса и проверкой вашего успешного пользовательского интерфейса. Это означает, что вам не нужно ждать, что делает ваши тесты еще быстрее!
Я надеюсь, что это поможет некоторым из моих товарищей там. Если вам нужно больше рекомендаций по этой теме, не стесняйтесь и ответьте на этот пост.
Cya!