Привет, Хабр! Меня зовут Ахмат. Я iOS QA Automation Engineer - в Vivid Money. В этой статье я хочу рассказать про взаимодействие с alerts и permissions в iOS тестах и показать, как их можно эффективно обрабатывать в своём проекте. Данная статья будет полезна начинающим iOS-автоматизаторам, либо разработчикам, которые решили изучить XCUITest и покрыть свой проект ui-тестами. В рамках статьи мы разберем: Что такое alerts и permissions вашего iOS приложения; Как обрабатывать alerts в коде теста, где они являются частью сценария; Как автоматически обрабатывать permissions; Как реализовать механизм включения и выключения alerts и permissions с помощью передачи аргументов при запуске тестов. Alerts - дают возможность предоставлять пользователям критически важную информацию.Например, alert может сообщать пользователю, что приложение запрашивает разрешение на отправку им нотификаций, и давать им возможность подтвердить или отклонить. Alerts появляются при первичном запуске вашего приложения. Permissions - позволяют приложениям запрашивать разрешение на использование настроек конфиденциальности. Например таких, как Location Services для определения вашего точного местоположения. Permissions появляются при первичном входе в раздел, к которому требуется запросить у вас разрешение. Способы взаимодействия с alerts - сделать их частью сценария (онбординг/авторизация и т.д) и кликать на нужные кнопки из кода теста или делать отдельный тест в наборе, который явно запускается первым и проходит все alerts при первом запуске приложения. Alerts находятся в иерархии текущего активного приложения, иногда это ваше тестируемое, иногда это springboard (встроенное приложение, которое управляет домашним экраном iOS). Наиболее эффективный способ - это обрабатывать alerts, когда они являются частью сценария. Создание отдельного теста для обработки всех alerts при первичном запуске может привести к нестабильности прогона всего тестового набора. Зачастую может произойти сбой во время прокликивания alerts, что в последствии приведет к частичному падению следующих тестов в наборе. В тестовый проект нужно добавить монитор прерывания пользовательского интерфейса. В XCTest есть метод, addUIInterruptionMonitor() который мы можем использовать для мониторинга и реагирования на появление permissions. Наиболее эффективно вызывать addUIInterruptionMonitor() в начале теста, где мы точно знаем что по сценарию появится permission. Вызов обработчика в setUp() не будет отрабатывать автоматически на всех тестах. Так же для каждого permission нужен отдельный вызов монитора прерывания пользовательского интерфейса. Можно включать появление alerts и permissions только в тех тестах, где они будут являться частью тестового сценария. Потребуется реализовать механизм управления добавлением в инициализацию делегатов, отвечающих за alerts и permissions. Реализуем механизм включения/выключения оповещения о трекинге активности. За появление диалогового окна трекинг менеджера в нашем приложении отвечает механизм ATTrackingManager. Создадим расширение для XCUIApplication, где напишем функцию launch с возможностью передачи аргументов: Далее нам потребуется выяснить в каком делегате у нас реализован вызов диалогового окна трекинг менеджера. Достаточно в поиске ввести ATTrackingManager и взять название делегата. Реализуем обработчик в AppDelegate и запуск ATTrackingManager в тестах, где аргумент “TrackingManager” не передается: Таким способом можно отключать все виды alerts и permissions по отдельности, как показано в примере выше или можно создать один общий аргумент для обработки добавления делегатов  в appDelegates, отвечающий за все виды alerts и permissions. Сочетая все три способа взаимодействия с alerts и permissions, можно сделать ваш код чистым и уменьшить число флаков при прогоне тесового набора.  R&D Mobile QA Automation Engineer