Мокинг API и поддержка тестов с помощью объектной модели страницы
Важность тестирования пользовательского интерфейса
Модульные тесты важны. Они следят за тем, чтобы наши функции работали правильно, что мы ничего не сломали, и выявляют крайние случаи.
Однако с точки зрения пользователя не имеет значения, не приведет ли нажатие кнопки подтверждения к ожидаемому экрану. Таким образом, UI-тестирование не заменяет модульное тестирование в вашем наборе тестов, а просто завершает его.
Проблемы тестирования пользовательского интерфейса
Я не знаю, сколько разработчиков поддерживают модульное тестирование с течением времени, но я знаю, что тестирование пользовательского интерфейса все еще довольно редко встречается среди разработчиков. На самом деле, по уважительным причинам.
Тестирование пользовательского интерфейса может быть сложно настроить, чтобы избежать разрыва с течением времени, по следующим причинам:
- Наше приложение работает с внутренним сервером, поэтому тесты становятся очень противоречивыми: проблемы с сетью или проблемы с сервером. Мы не контролируем запросы, возвращаемые с сервера.
- Написание сценариев тестирования пользовательского интерфейса занимает много времени. Поиск кнопок или управление перемещением между экранами для одного теста. И затем нам нужно продублировать код, когда мы хотим создать новый тестовый пример.
- Тесты не только долго писать, они еще и не очень удобочитаемы. Попытайтесь понять их через два дня после их создания, и вы поймете, о чем я.
- UI постоянно меняется. Мы добавляем и удаляем кнопки, экраны, прокрутки и многое другое. Обновление тестов становится кошмаром каждый раз, когда мы хотим внести небольшое изменение.
Смоделируйте свой бэкэнд
Большинство мобильных приложений работают с внутренним сервером, и для тестирования пользовательского интерфейса это может быть проблемой.
Первое правило любого автоматического тестирования заключается в том, что если вы запускаете тесты 1000 раз, вы должны ожидать каждый раз одни и те же результаты. Итак, проблемы с сервером и сетью делают ваши тесты ненадежными.
Но если вы будете следовать SoC (разделение задач), вы можете смоделировать свой внутренний сервер, создав фиктивный сервер, внедрив его на свой сетевой уровень и сделав свой тест полностью надежным и предсказуемым.
Многие инструменты могут помочь вам имитировать ваш сервер, но принципы всегда одни и те же - замените свой сервер локальным компонентом, который возвращает предсказуемые и надежные объекты ответа на ваши сетевые запросы.
Чтобы протестировать свое приложение в различных случаях (вход, выход, синхронизация данных и т. Д.), Вы можете сохранить фиктивные данные запрос-› ответ в разные файлы JSON , где каждый файл представляет разные сценарии (журнал- в, зарегистрируйтесь).
Вы загружаете свой тест с предпочитаемым файлом с помощью параметров запуска, поэтому вы не только решаете проблемы с надежностью, но также можете протестировать свое приложение с различными случаями.
Но чтобы собрать все насмешливые данные, нужно время!
Вы разработчик, творите чудеса! Записывайте запросы и ответы при однократном запуске приложения. Вы можете сделать это с помощью Charles Proxy или написать код, сохраняющий все сетевые данные в файл.
Мокинг других API
Этот метод не обязательно заканчивается издевательством над вашим сервером. Вы также можете издеваться над другими API.
Например, предположим, что у вас есть приложение, которое управляет контактами адресной книги и синхронизируется с адресной книгой устройства.
Опять же, если вы отделили коннектор адресной книги от остальной части приложения и следовали шаблонам проектирования, ориентированным на протокол, вы можете заменить коннектор фиктивной адресной книгой и возвращать различные объекты контакта, независимо от того, какая адресная книга находится на устройстве в настоящее время.
То же самое касается календарей, напоминаний и других системных API.
Ведение тестов с помощью объектной модели страницы
Написание сценариев тестирования пользовательского интерфейса требует времени и усилий, но настоящая проблема заключается в том, как поддерживать его с течением времени.
Самый простой способ решить эту проблему - создать нечто, называемое объектной моделью страницы.
Объектная модель страницы - это объект, прикрепленный к экрану. В нем есть ссылка на XCUIApplication, и в его обязанности входит выполнение действий на странице, поиск элементов и возврат объекта следующей страницы, если это необходимо.
Обратите внимание, что я не планирую показывать вам, как писать сценарии тестирования пользовательского интерфейса, а, скорее, я хотел бы показать вам, как решать повседневные проблемы, возникающие при настройке хорошей инфраструктуры тестирования для вашего приложения.
Принципы объектов страницы заключаются в том, что мы отделяем тестовый сценарий от обработки макета.
Это позволяет нам быстро писать очень маленькие, удобочитаемые тесты пользовательского интерфейса и в то же время повторно использовать тяжелую работу, создавая специальный объект для каждого экрана.
Кроме того, когда ваш пользовательский интерфейс изменяется, все, что вам нужно сделать, это изменить соответствующие методы в вашем объекте страницы, не касаясь реальных тестовых случаев.
Заключение
Это было краткое введение о том, как решить проблемы с тестированием пользовательского интерфейса.
Как я уже сказал, существуют дополнительные и более сложные инструменты, такие как настройка локального сервера для имитации, Шаблон сценария или файлы конфигурации Xcode. Я постараюсь рассказать об этом в следующих статьях.
Самым важным является то, что вам необходимо настроить стабильную, читаемую и многократно используемую инфраструктуру тестирования пользовательского интерфейса и перестать тратить драгоценное время, позволив Xcode выполнить проверку работоспособности за вас.
