Как джун внедрял Allure с XCTest: опыт автоматизации тестирования iOS

QA-инженер Сергей развивает автоматизацию тестирования приложения Kolesa.kz. В статье поделился опытом настройки Allure TestOps для автотестов на платформе iOS, описав технические сложности и пути их решения.

Материал будет полезен как для новичков, так и для опытных QA-инженеров, которые стремятся улучшить свои процессы тестирования и отчётности.

Задача

Изначально для работы с тест-кейсами, тест-планами и чек-листами использовалась TMS (Test Management System), но автотесты писались отдельно, и не были с ней интегрированы. Это создавало сложности:

1. Тесты не были связаны с TMS: код автотестов "не знал" о существовании тест-кейсов в TMS. Следовательно, в системе не отображалась статистика прогонов ui-тестов.
2. Отсутствовал единый источник данных: результаты автотестов отслеживались в CI, а для отчётности использовался XCTestHTMLReport. Этого было недостаточно для полноценного анализа стабильности автотестов.

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

Поиск решения:

Задача интеграции автотестов с Allure казалась сложной, но вдохновляющей. Исследование статей и гайдов помогли понять структуру кейсов в Allure “под капотом”, особенно анализ структуры JSON тест-кейса. Это позволило наглядно связать автотесты с Allure и структурировать отчёты.

Для решения вопроса интеграции автотестов с Allure – первым этапом требовалось добавить Allure в проект. Благодаря интуитивно понятной документации Allure, автотестировщиками Android-приложения уже были добавлены Allure и аннотации. Однако для IOS дела обстояли сложнее ввиду отсутствия официального руководства.

Аннотации шли следующим этапом после добавления Allure. Здесь помог подход из статьи по внедрению отчётности в UI-тесты. В итоге у нас имелось два метода-аннотаций (feature и link), и пара вспомогательных методов для этих самых аннотаций:

Скрин 1. Результат запуска теста с link и feature

Решение

1. Интеграция Allure с iOS-проектом:

Решение вопроса началось с поиска информации. Рекомендации из статьи помогли подключить базовые аннотации feature и link к автотестам — результаты интеграции мгновенно отразились Allure-отчётах (Скрин 1)

Однако возникли новые вопросы:

• Как связать тесты с конкретными кейсами через allureId?
• Как добавить доступное и содержательное название кейсу, чтобы упростить анализ отчётов?

2. Разработка методов для аннотаций Allure:

Можно было бы оставить только feature и link, однако сравнив аннотации автотестов iOS с аннотациями автотестов Android оказалось, что не будет получена оптимальная структура. На проекте iOS аннотация feature выполняла функцию отображения названия тест-кейса, а на Android для каждого отдельного параметра из Allure имелась своя аннотация:

Подробное описание аннотаций представлено ниже:

• AllureId – уникальный идентификатор тест-кейса в Allure. С помощью этого параметра автотест можно связать с конкретным тест-кейсом в TMS, а также применить изменения к тест-кейсу после прогона.
• Feature – группа тестов, связанных с определённым функционалом. Например, все кейсы, касающиеся авторизации в проекте, объединяются в одну фичу "Авторизация".
• Story – подгруппа кейсов внутри фичи, например, "Авторизация с разных экранов". Она позволяет организовать тесты внутри фичи по конкретным сценариям.
• DisplayName – аннотация, которая позволяет задать "человеческое" название для каждого тест-кейса. Тест-кейсы в отчетах отображаются по заданному в коде автотеста имени.

После запуска автотеста на Android, в Allure отображается следующее:

Скрин 2. Результат прогона теста на Android с аннотациями

Такой подход понятен и имеет чёткую структуру. Поэтому, было решено реализовать на iOS такие же аннотации, как на Android.

Первым этапом был добавлен метод story(), его реализация описана в статье Внедрение Allure (отчётность) в UI-тесты (swift, XCTest), и выглядит следующим образом:

Анализ параметров
Чтобы указать параметры Feature, Story и Link тест-кейса используются вспомогательные private методы к ним: links() и label(). Feature и Story — это параметры тест-кейса в Allure. Чтобы задать им значение, необходимо обратиться с помощью вспомогательного метода label(), который включает путь к параметру: allure.label.feature для Feature и allure.label.story для Story. 

Добавление параметра displayName в автотесты
Возникла мысль попробовать реализовать метод displayName так же через метод label(), как allure.label.name — достаточно написать новый метод и использовать уже существующий метод label(), как вспомогательный к нему:

Спойлер: это не сработает. Поэтому вопрос какой путь использовать для того, чтобы дать название тест-кейсу, остаётся открытым.

Спустя два дня исследования был найден инсайт из документации Allure, что параметры Epic, Feature, Story и Suite задаются одинаково через лейблы: allure.label.epic/feature/story/suite:LabelName. А так как name не лежит в лэйблах — задать значение через allure.label.name не получится. Неожиданно решение пришло из статьи, тема которой была далека от поставленной задачи — она касалась экспорта данных из Allure в Confluence. В примерах JSON-структуры, приведённой в статье, было описано, как задаётся имя тест-кейса, и это помогло применить решение в своём проекте. Выглядит JSON тест-кейса следующим образом:

 

Сравнивая путь к параметру Story в коде с JSON, то можно заметить, что он задаётся через allure.label.story:StoryName, так как story вложен в labels. В той же JSON-структуре параметр name обособлен, что навело на мысль, что путь к имени тест-кейса тоже должен быть обособленным — через allure.name. На основе этого предположения были написаны методы для обозначения имени тест-кейса. После их тестирования решение оказалось рабочим.

Скрин 3. Прогон тестов с указанием Feature, Story, DisplayName и Link

Feature, Story и DisplayName успешно добавлены, однако при сравнении link и allureId тест-кейсов возникла проблема: при прогоне автотестов Allure создал новый тест-кейс, разместив его по указанному пути, а затем связал его с существующим аналогичным тест-кейсом, что привело к дублированию. Возникла задача: применить изменения только к тест-кейсу с указанным allureId.

Решение найдено быстро. Параметр id не является вложенным, поэтому была использована аналогичная логика, как для name. Подтверждение решения было найдено в документации Allure Mocha Reference. Несмотря на отличие Mocha от XCTest, механика схожа. Далее были написаны методы для указания уникального идентификатора тест-кейса:

После прогона получен желаемый результат:

Скрин 4. Прогон тестов с указанием Feature, Story, DisplayName и AllureId

Кейсы больше не дублируются, и все изменения, указанные в коде, корректно применяются только к одному тест-кейсу с указанным allureId.

Заключение

Опыт внедрения Allure в iOS-проект показал, что даже при отсутствии готовых решений можно найти выход из сложных ситуаций. Ключевым фактором стало детальное изучение структуры тест-кейсов в  Allure, а именно их JSON.

Совет начинающим инженерам: не стоит избегать сложных задач. Каждый новый вызов — это шаг к профессиональному росту. Эксперименты и исследования открывают новые возможности, главное — учитывать безопасность и интересы команды.

Ниже представлен итоговый код,  который по итогам исследования получилось написать и применить к более чем 70 ui-тестам на проекте, использующем Allure + XCTest.