Numele meu este Dmitry, lucrez ca tester în companie . Destul de recent am terminat de a face cu o caracteristică relativ recentă de la — și anume, cu testarea instrumentală a aplicațiilor iOS folosind cadrul de testare nativ XCUITest.
Înainte de aceasta, încercasem deja Firebase Test Lab pentru Android și îmi plăcea foarte mult totul, așa că am decis să încerc să pun infrastructura de testare iOS a proiectului pe același picior. A trebuit să caut mult pe Google și nu totul a funcționat prima dată, așa că am decis să scriu un articol tutorial pentru cei care încă se luptă.
Deci, dacă aveți teste UI pe un proiect iOS, puteți încerca deja să le rulați pe dispozitive reale astăzi, oferite cu amabilitate de Good Corporation. Pentru cei interesați, bine ați venit la cat.
În poveste, am decis să construiesc pe câteva date inițiale - un depozit privat pe GitHub și sistemul de construire CircleCI. Numele aplicației este AmazingApp, bundleID este com.company.amazingapp. Prezint aceste date imediat pentru a reduce confuzia ulterioară.
Dacă ai implementat diferit anumite soluții în proiectul tău, împărtășește-ți experiența în comentarii.
1. Testele în sine
Creați o nouă ramură de proiect pentru testele UI:
$ git checkout develop
$ git pull
$ git checkout -b “feature/add-ui-tests”
Să deschidem proiectul în XCode și să creăm o nouă țintă cu teste de UI [XCode -> Fișier -> Nou -> Țintă -> Pachet de testare iOS], dându-i numele auto-explicativ AmazingAppUITests.
Accesați secțiunea Build Phases a țintei create și verificați prezența Dependențelor țintă - AmazingApp, în Surse de compilare - AmazingAppUITests.swift.
O bună practică este separarea diferitelor opțiuni de construcție în scheme separate. Creăm o schemă pentru testele noastre UI [XCode -> Product -> Scheme -> New Scheme] și îi dăm același nume: AmazingAppUITests.
Construirea schemei create trebuie să includă ținta aplicației principale - teste AmazingApp și Target UI - AmazingAppUITests - vezi captura de ecran
Apoi, creăm o nouă configurație de construcție pentru testele UI. În XCode, faceți clic pe fișierul de proiect și accesați secțiunea Info. Faceți clic pe „+” și creați o nouă configurație, de exemplu XCtest. Vom avea nevoie de asta pe viitor pentru a evita dansul cu tamburinul când vine vorba de semnarea codului.
Există cel puțin trei Ținte în proiectul dvs.: aplicația principală, testele unitare (la urma urmei, ele există, nu?) și testele UI pe care le-am creat.
Accesați Target AmazingApp, fila Build Settings, secțiunea Code Signing Identity. Pentru configurația XCtest, selectați iOS Developer. În secțiunea Stil semnare cod, selectați Manual. Nu am generat încă un profil de aprovizionare, dar cu siguranță vom reveni la el puțin mai târziu.
Pentru Target AmazingAppUITests facem același lucru, dar în coloana Product Bundle Identifier introducem com.company.amazingappuitests.
2. Configurarea unui proiect în Programul pentru dezvoltatori Apple
Accesați pagina Apple Developer Program, accesați secțiunea Certificate, Identifiers & Profiles și apoi la coloana App ID-uri a articolului Identificatori. Creați un nou ID de aplicație numit AmazingAppUITests și bundleID com.company.amazingappuitests.
Acum avem ocazia să ne semnăm testele cu un certificat separat, dar... Procedura de asamblare a unei build pentru testare implică asamblarea aplicației în sine și asamblarea runner-ului de testare. În consecință, ne confruntăm cu problema semnării a două ID-uri de pachet cu un singur profil de furnizare. Din fericire, există o soluție simplă și elegantă - Wildcard App ID. Repetăm procedura pentru crearea unui nou ID de aplicație, dar în loc de ID explicit de aplicație, selectați ID de aplicație Wildcard ca în captura de ecran.
În acest moment, am terminat de lucrat cu developer.apple.com, dar nu vom minimiza fereastra browserului. Să mergem la și citiți despre utilitarul Match din scoarță în scoarță.
Un cititor atent a observat că pentru a folosi acest utilitar vom avea nevoie de un depozit privat și de un cont cu acces atât la Apple Developer Program, cât și la Github. Creăm (dacă dintr-o dată nu există așa ceva) un cont al formularului [e-mail protejat], veniți cu o parolă puternică, înregistrați-o la developer.apple.com și numiți-o ca administrator de proiect. Apoi, acordăm contului acces la depozitul github al companiei dvs. și creăm un nou depozit privat cu un nume precum AmazingAppMatch.
3. Configurarea Fastlane și a utilitarului de potrivire
Deschideți un terminal, accesați folderul cu proiectul și inițializați Fastlane așa cum este indicat în . După introducerea comenzii
$ fastlane initVi se va solicita să selectați configurațiile de utilizare disponibile. Selectați a patra opțiune - configurarea manuală a proiectului.
Proiectul are un nou director fastlane, care conține două fișiere - Appfile și Fastfile. Pe scurt, stocăm datele de serviciu în Appfile și scriem joburi în Fastfile, numite benzi în terminologia Fastlane. Vă recomand să citiți documentația oficială: , .
Deschideți Appfile în editorul de text preferat și aduceți-l în următorul formular:
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
Ne întoarcem la terminal și conform manualului oficial începem să configuram meciul.
$ fastlane match init
$ fastlane match development
Apoi, introduceți datele solicitate - depozit, cont, parolă etc.
Important: Când lansați pentru prima dată utilitarul de potrivire, vi se va cere să introduceți o parolă pentru a decripta depozitul. Este foarte important să salvați această parolă; vom avea nevoie de ea la configurarea serverului CI!
Un fișier nou a apărut în folderul Fastlane - Matchfile. Deschideți-l în editorul de text preferat și afișați-l astfel:
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
O completăm exact în acest fel dacă dorim să folosim potrivirea în viitor pentru a semna versiuni pentru afișare în Crashlytics și/sau AppStore, adică pentru a semna ID-ul pachetului al aplicației dvs.
Dar, după cum ne amintim, am creat un ID Wildcard special pentru a semna versiunea de testare. Prin urmare, deschideți Fastfile și introduceți o nouă bandă:
lane :testing_build_for_firebase do
match(
type: "development",
readonly: true,
app_identifier: "com.company.*",
git_branch: "uitests" # создаем отдельный бранч для development сертификата для подписи тестовой сборки.
)
end
Salvați și intrați în terminal
fastlane testing_build_for_firebaseși vedem cum fastlane a creat un nou certificat și l-a pus în depozit. Grozav!
Deschideți XCode. Acum avem profilul de aprovizionare necesar al formularului Match Development com.company.*, care trebuie specificat în secțiunea Profil de aprovizionare pentru țintele AmazingApp și AmazingAppUITests.
Rămâne să adăugați o bandă pentru testele de asamblare. Să mergem la un proiect plugin pentru fastlane care facilitează configurarea exportului în Firebase Test Lab și urmați instrucțiunile.
Să copiem și să lipim din exemplul original, astfel încât lane testing_build_for_firebase să arate astfel:
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
Pentru informații complete despre configurarea fastlane în CircleCI, vă recomand să citiți documentația oficială .
Nu uitați să adăugați o nouă sarcină la 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. Dar bancul nostru de testare? Configurarea Firebase.
Să trecem la ce a fost scris articolul.
Poate că aplicația dvs. folosește Firebase pe un plan gratuit, sau poate deloc. Nu există absolut nicio diferență fundamentală, deoarece pentru nevoile de testare putem crea un proiect separat cu un an de utilizare gratuită (mișto, nu?)
Ne conectăm la contul nostru de infrastructură (sau la oricare altul, nu contează) și mergem la . Creați un nou proiect numit AmazingAppUITests.
Important: În pasul anterior din Fastfile în banda firebase_test_lab_ios_xctest, parametrul gcp_project ar trebui să se potrivească cu numele proiectului.
Setările implicite ni se potrivesc destul de bine.
Nu închideți fila, înregistrați-vă sub același cont în - aceasta este o măsură necesară, deoarece comunicarea cu Firebase are loc utilizând interfața consolei gcloud.
Google dă 300 de dolari pentru un an, ceea ce în contextul efectuării autotestelor echivalează cu un an de utilizare gratuită a serviciului. Introducem informațiile dvs. de plată, așteptăm debitul de test de 1 USD și primim 300 USD în contul dvs. După un an, proiectul va fi transferat automat într-un plan tarifar gratuit, astfel încât nu este nevoie să vă faceți griji cu privire la o posibilă pierdere de bani.
Să revenim la fila cu proiectul Firebase și să-l transferăm în planul tarifar Blaze - acum avem ceva de plătit dacă se depășește limita.
În interfața gcloud, selectați proiectul nostru Firebase, selectați elementul din meniul principal „Director” și adăugați API-ul Cloud Testing și API-ul Cloud Tools Result.
Apoi accesați elementul de meniu „IAM și administrare” -> Conturi de serviciu -> Creare cont de serviciu. Acordăm drepturi de editare a proiectului.
Creați o cheie API în format JSON
Vom avea nevoie de JSON descărcat puțin mai târziu, dar deocamdată vom considera configurarea Test Lab completă.
5. Configurarea CircleCI
Apare o întrebare rezonabilă - ce să faci cu parolele? Mecanismul variabil de mediu al mașinii noastre de construcție ne va ajuta să ne stocăm în siguranță parolele și alte date sensibile. În setările proiectului CircleCI, selectați Variabile de mediu
Și configurați următoarele variabile:
- cheie: GOOGLE_APPLICATION_CREDENTIALS
valoare: conținutul fișierului json al cheii contului de serviciu gcloud - cheie: MATCH_PASSWORD
valoare: parola pentru decriptarea depozitului github cu certificate - cheie: FASTLANE_PASSWORD
valoare: parola contului de infrastructură Apple Developer Portal
Salvăm modificările, creăm un PR și îl trimitem șefului echipei noastre pentru examinare.
Rezultatele
Ca urmare a acestor manipulări simple, am primit un suport de lucru bun, stabil, cu capacitatea de a înregistra videoclipuri pe ecranul dispozitivului în momentul testării. În exemplul de testare, am specificat modelul de dispozitiv iPhone X, dar ferma oferă o selecție bogată dintr-o combinație de diferite modele și versiuni iOS.
A doua parte va fi dedicată configurației pas cu pas a Firebase Test Lab pentru un proiect Android.
Sursa: www.habr.com