Меня зовут Дмитрий, я работаю тестировщиком в компании . Совсем недавно я закончил разбираться со сравнительно свежей фичей от — а именно, с инструментальным тестированием iOS приложений с использованием нативного фреймворка тестирования XCUITest.
До этого я уже распробовал Firebase Test Lab для Android и мне все очень понравилось, так что я решил попробовать поставить тестовую инфраструктуру iOS проекта на те же рельсы. Приходилось очень много гуглить и не все получалось с первого раза, поэтому я решил написать статью-туториал для тех, кому все еще это предстоит.
Итак, если у вас есть UI тесты на iOS проекте, вы сможете уже сегодня попробовать запустить их на реальных девайсах, любезно предоставленных Корпорацией Добра. Заинтересованным — добро пожаловать под кат.
В повествовании я решил отталкиваться от некоторых исходных данных — приватный репозиторий на GitHub и система сборки CircleCI. Название приложения — AmazingApp, bundleID — com.company.amazingapp. Эти данные я привожу сразу, для уменьшения последующей путаницы.
Если те или иные решения в своем проекте вы реализовали по-другому — делитесь опытом в комментариях.
1. Сами тесты
Создаем новую ветку проекта для UI тестов:
$ git checkout develop
$ git pull
$ git checkout -b “feature/add-ui-tests”
Откроем проект в XCode и создадим новую Цель (Target) с UI тестами [XCode -> File -> New -> Target -> iOS Testing Bundle], даем ей говорящее название AmazingAppUITests.
Переходим в секцию Build Phases созданного Target и проверяем наличие Target Dependencies — AmazingApp, в Compile Sources — AmazingAppUITests.swift.
Хорошей практикой является выделение различных вариантов сборки в отдельные Схемы (Schemes). Создаем схему для наших UI тестов [XCode -> Product -> Scheme -> New Scheme] и даем ей такое же название: AmazingAppUITests.
Build созданной схемы должен включать в себя Target основного приложения — AmazingApp и Target UI тестов — AmazingAppUITests — см.скриншот
Далее, создаем новую конфигурацию сборки для UI тестов. В XCode кликаем по файлу проекта, переходим в секцию Info. Кликаем на “+” и создаем новую конфигурацию, например XCtest. Это потребуется нам в дальнейшем, дабы избежать плясок с бубном когда дело дойдет до code signing.
В вашем проекте есть по крайней мере три Target: основное приложение, юнит тесты (ведь они есть, не так ли?) и созданный нами Target UI тестов.
Заходим в Target AmazingApp, вкладка Build Settings, раздел Code Signing Identity. Для конфигурации XCtest выбираем iOS Developer. В разделе Code Signing Style выбираем Manual. Provisioning profile мы еще не сгенерировали, но чуть позже обязательно к нему вернемся.
Для Target AmazingAppUITests делаем то же самое, но в графу Product Bundle Identifier вписываем com.company.amazingappuitests.
2. Настройка проекта в Apple Developer Program
Заходим на страницу Apple Developer Program, переходим в раздел Certificates, Identifiers & Profiles и затем в графу App IDs пункта Identifiers. Создаем новый App ID с именем AmazingAppUITests и bundleID com.company.amazingappuitests.
Теперь у нас есть возможность подписывать наши тесты отдельным сертификатом, но… Процедура сборки билда для тестирования подразумевает сборку самого приложения и сборки раннера тестов. Соответственно, мы сталкиваемся с проблемой подписи двух bundle ID одним provisioning profile. Благо, существует простое и элегантное решение — Wildcard App ID. Повторяем процедуру создания нового App ID, но вместо Explicit App ID выбираем Wildcard App ID как на скриншоте.
На этом этапе работа с developer.apple.com окончена, но сворачивать окно браузера мы не будем. Идем на и читаем про утилиту Match от корки до корки.
Внимательный читатель заметил, что для использования этой утилиты нам понадобится приватный репозиторий и аккаунт, имеющий доступ как к Apple Developer Program, так и к Github. Создаем (если вдруг такого нет) аккаунт вида [email protected], придумываем мощный пароль, регистрируем его в developer.apple.com, назначаем администратором проекта. Далее, даем аккаунту доступ к github репозиторию вашей компании и создаем новый приватный репозиторий с именем вроде AmazingAppMatch.
3. Настройка Fastlane и утилиты match
Открываем терминал, переходим в папку с проектом и инициализируем fastlane как указано в . После ввода команды
$ fastlane initбудет предложено выбрать доступные конфигурации использования. Выбираем четвертый пункт — ручная настройка проекта.
В проекте появилась новая директория fastlane, в которой лежат два файла — Appfile и Fastfile. В двух словах — в Appfile мы храним служебные данные, а в Fastfile прописываем jobs, в терминологии Fastlane именуемые lanes. Рекомендую к прочтению официальную документацию: , .
Открываем Appfile в любимом текстовом редакторе и приводим его к следующему виду:
app_identifier "com.company.amazingapp" # Bundle ID
apple_dev_portal_id "[email protected]" # Созданный инфраструктурный аккаунт, имеющий право на редактирование iOS проекта в Apple Developer Program.
team_id "LSDY3IFJAY9" # Your Developer Portal Team ID
Возвращаемся в терминал и по официальному мануалу начинаем настраивать match.
$ fastlane match init
$ fastlane match development
Далее вводим запрашиваемые данные — репозиторий, аккаунт, пароль и т.д.
Важно: при первом запуске утилита match попросит ввести пароль для дешифровки репозитория. Очень важно сохранить этот пароль, на этапе настройки CI сервера он нам пригодится!
В папке fastlane появился новый файл — Matchfile. Открываем в любимом текстовом редакторе и приводим к виду:
git_url("https://github.com/YourCompany/AmazingAppMatch") #Созданный приватный репозиторий для хранения сертификатов и профайлов.
type("development") # The default type, can be: appstore, adhoc, enterprise or development
app_identifier("com.company.amazingapp")
username("[email protected]") # Your Infrastructure account Apple Developer Portal username
Заполняем именно таким образом, если хотим в дальнейшем использовать match для подписи билдов для выкладки в Crashlytics и/или AppStore, т.е для подписи bundle ID вашего приложения.
Но, как мы помним, для подписи тестового билда мы создали специальный Wildcard ID. Поэтому, открываем Fastfile и вписываем новый lane:
lane :testing_build_for_firebase do
match(
type: "development",
readonly: true,
app_identifier: "com.company.*",
git_branch: "uitests" # создаем отдельный бранч для development сертификата для подписи тестовой сборки.
)
end
Сохраняем, вводим в терминал
fastlane testing_build_for_firebaseи видим как fastlane создал новый сертификат и положил его в репозиторий. Отлично!
Открываем XCode. Теперь у нас есть нужный provisioning profile вида Match Development com.company.*, который нужно указать в секции Provisioning profile для таргетов AmazingApp и AmazingAppUITests.
Осталось дописать lane для сборки тестов. Идем в проекта плагина для fastlane, облегчающего настройку экспорта в Firebase Test Lab и следуем инструкциям.
Копипастим из исходного примера, чтобы наш lane testing_build_for_firebase в итоге выглядел так:
lane :testing_build_for_firebase do
match(
type: "development",
readonly: true,
app_identifier: "com.company.*",
git_branch: "uitests"
)
scan(
scheme: 'AmazingAppUITests', # UI Test scheme
clean: true, # Recommended: This would ensure the build would not include unnecessary files
skip_detect_devices: true, # Required
build_for_testing: true, # Required
sdk: 'iphoneos', # Required
should_zip_build_products: true, # Must be true to set the correct format for Firebase Test Lab
)
firebase_test_lab_ios_xctest(
gcp_project: 'AmazingAppUITests', # Your Google Cloud project name (к этой строчке вернемся позже)
devices: [ # Device(s) to run tests on
{
ios_model_id: 'iphonex', # Device model ID, see gcloud command above
ios_version_id: '12.0', # iOS version ID, see gcloud command above
locale: 'en_US', # Optional: default to en_US if not set
orientation: 'portrait' # Optional: default to portrait if not set
}
]
)
end
Для получения полной информации о настройке fastlane в CircleCI рекомендую к прочтению официальную документацию .
Не забываем дополнить наш config.yml новой задачей:
build-for-firebase-test-lab:
macos:
xcode: "10.1.0"
working_directory: ~/project
shell: /bin/bash --login -o pipefail
steps:
- checkout
- attach_workspace:
at: ~/project
- run: sudo bundle install # обновляем зависимости
- run:
name: install gcloud-sdk # на mac машину необходимо установить gcloud
command: |
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" < /dev/null 2> /dev/null ; brew install caskroom/cask/brew-cask 2> /dev/null
brew cask install google-cloud-sdk
- run:
name: build app for testing
command: fastlane testing_build_for_firebase # запускаем lane сборки и отправки в firebase
4. А как же наш тестовый стенд? Настраиваем Firebase.
Приступим, собственно, к тому, для чего статья и писалась.
Возможно, ваше приложение использует Firebase на бесплатном тарифном плане, возможно — не использует вовсе. Принципиальной разницы абсолютно нет, потому как для нужд тестирования мы можем создать отдельный проект с годом бесплатного использования (круто, да?)
Логинимся в наш инфраструктурный аккаунт (или любой другой, без разницы), и идем на . Создаем новый проект с именем AmazingAppUITests.
Важно: В предыдущем шаге в Fastfile в lane firebase_test_lab_ios_xctest параметр gcp_project должен соответствовать названию проекта.
Дефолтные настройки нас вполне устраивают.
Не закрываем вкладку, под тем же аккаунтом регистрируемся в — это вынужденная мера, так как общение с Firebase происходит с помощью интерфейса консоли gcloud.
Google дарит 300$ на год, что в контексте выполнения автотестов эквивалентно году бесплатного использования сервиса. Вводим платежные данные, дожидаемся тестового списания 1$ и получаем 300$ на счет. По прошествии года проект будет автоматически переведен на бесплатный тарифный план, так что волноваться о возможной потере денег не стоит.
Вернемся на вкладку с проектом Firebase и переведем его на тарифный план Blaze — теперь нам есть чем платить в случае превышения лимита.
В интерфейсе gcloud выбираем наш Firebase проект, выбираем пункт главного меню «Каталог» и добавляем Cloud Testing API и Cloud Tools Result API.
Затем переходим в пункт меню «IAM и администрирование» -> Сервисные аккаунты -> Создать сервисный аккаунт. Выдаем права на редактирование проекта.
Создаем API ключ в формате JSON
Скачанный JSON понадобится нам чуть позже, а пока настройку Test Lab будем считать оконченной.
5. Настройка CircleCI
Назревает резонный вопрос — а что делать с паролями? Надежно сохранить наши пароли и прочие чувствительные данные нам поможет механизм переменных окружения нашей билд-машины. В настройках проекта CircleCI выбираем Environment Variables
И заводим следующие переменные:
- key: GOOGLE_APPLICATION_CREDENTIALS
value: содержимое json файла ключа сервисного аккаунта gcloud - key: MATCH_PASSWORD
value: пароль для дешифровки github репозитория с сертификатами - key: FASTLANE_PASSWORD
value: пароль инфраструктурного аккаунта Apple Developer Portal
Сохраняем изменения, создаем PR и отправляем на review своему тимлиду.
Итоги
В результате выполнение этих нехитрых манипуляций мы получили хороший, стабильно работающий стенд с возможностью записи видео на экране устройства в момент прохождения тестирования. В тестовом примере я указал модель устройства iPhone X, но ферма предоставляет богатый выбор из комбинации различных моделей и версий iOS.
Вторая часть будет посвящена пошаговой настройке Firebase Test Lab для Android проекта.
Источник: habr.com