Мяне клічуць Зміцер, я працую тэсціроўшчыкам у кампаніі . Зусім нядаўна я скончыў разбірацца з параўнальна свежай фічай ад — а менавіта, з інструментальным тэсціраваннем 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. Ствараем (калі раптам такога няма) акаўнт выгляду [электронная пошта абаронена], прыдумляем магутны пароль, рэгіструем яго ў 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