Jeg heter Dmitry, jeg jobber som tester i selskapet . Ganske nylig ble jeg ferdig med å behandle et relativt ferskt innslag fra – nemlig med instrumentell testing av iOS-applikasjoner ved å bruke det native testrammeverket XCUITest.
Før dette hadde jeg allerede prøvd Firebase Test Lab for Android og likte alt, så jeg bestemte meg for å prøve å sette iOS-testinfrastrukturen til prosjektet på samme fot. Jeg måtte Google mye og ikke alt fungerte første gang, så jeg bestemte meg for å skrive en opplæringsartikkel for de som fortsatt sliter.
Så hvis du har UI-tester på et iOS-prosjekt, kan du allerede prøve å kjøre dem på ekte enheter i dag, vennligst levert av Good Corporation. For de interesserte, velkommen til katt.
I historien bestemte jeg meg for å bygge på noen innledende data - et privat depot på GitHub og CircleCI-byggesystemet. Applikasjonsnavnet er AmazingApp, bundleID er com.company.amazingapp. Jeg presenterer disse dataene umiddelbart for å redusere påfølgende forvirring.
Hvis du implementerte visse løsninger i prosjektet ditt annerledes, del erfaringen din i kommentarene.
1. Selve testene
Opprett en ny prosjektgren for UI-tester:
$ git checkout develop
$ git pull
$ git checkout -b “feature/add-ui-tests”
La oss åpne prosjektet i XCode og lage et nytt mål med UI-tester [XCode -> Fil -> Nytt -> Target -> iOS Testing Bundle], som gir det det selvforklarende navnet AmazingAppUITests.
Gå til Build Phases-delen av det opprettede målet og se etter tilstedeværelsen av Target Dependencies - AmazingApp, i Compile Sources - AmazingAppUITests.swift.
En god praksis er å dele forskjellige byggealternativer i separate ordninger. Vi oppretter et opplegg for våre UI-tester [XCode -> Produkt -> Scheme -> New Scheme] og gir det samme navn: AmazingAppUITests.
Bygget av det opprettede opplegget må inkludere målet for hovedapplikasjonen - AmazingApp og Target UI-tester - AmazingAppUITests - se skjermbilde
Deretter oppretter vi en ny byggekonfigurasjon for UI-tester. I XCode klikker du på prosjektfilen og går til Info-delen. Klikk på "+" og lag en ny konfigurasjon, for eksempel XCtest. Dette vil vi trenge i fremtiden for å slippe å danse med tamburin når det gjelder kodesignering.
Det er minst tre mål i prosjektet ditt: hovedapplikasjonen, enhetstester (de eksisterer tross alt, ikke sant?) og Target UI-testene vi har laget.
Gå til Target AmazingApp, Build Settings-fanen, Code Signing Identity-delen. For XCtest-konfigurasjonen, velg iOS Developer. I delen Kodesigneringsstil velger du Manuell. Vi har ikke generert en klargjøringsprofil ennå, men vi kommer definitivt tilbake til den litt senere.
For Target AmazingAppUITests gjør vi det samme, men i kolonnen Product Bundle Identifier skriver vi inn com.company.amazingappuitests.
2. Sette opp et prosjekt i Apple Developer Program
Gå til Apple Developer Program-siden, gå til Sertifikater, Identifikatorer og Profiler-delen og deretter til App ID-kolonnen i Identifikatorer-elementet. Opprett en ny app-ID kalt AmazingAppUITests og bundleID com.company.amazingappuitests.
Nå har vi muligheten til å signere testene våre med et eget sertifikat, men... Prosedyren for å sette sammen en build for testing innebærer å montere selve applikasjonen og montere testløperen. Følgelig står vi overfor problemet med å signere to pakke-ID-er med én klargjøringsprofil. Heldigvis finnes det en enkel og elegant løsning – Wildcard App ID. Vi gjentar prosedyren for å lage en ny app-ID, men i stedet for eksplisitt app-ID, velg jokertegn app-ID som på skjermbildet.
På dette tidspunktet er vi ferdige med å jobbe med developer.apple.com, men vi vil ikke minimere nettleservinduet. La oss gå til og les om Match-verktøyet fra perm til perm.
En oppmerksom leser la merke til at for å bruke dette verktøyet trenger vi et privat depot og en konto med tilgang til både Apple Developer Program og Github. Vi lager (hvis det plutselig ikke er noe slikt) en konto for skjemaet [e-postbeskyttet], kom opp med et sterkt passord, registrer det hos developer.apple.com, og utnevne det som prosjektadministrator. Deretter gir vi kontoen tilgang til bedriftens github-depot og oppretter et nytt privat depot med et navn som AmazingAppMatch.
3. Sette opp Fastlane og kampverktøyet
Åpne en terminal, gå til mappen med prosjektet og initialiser fastlane som angitt i . Etter å ha lagt inn kommandoen
$ fastlane initDu vil bli bedt om å velge tilgjengelige brukskonfigurasjoner. Velg det fjerde alternativet - manuell prosjektoppsett.
Prosjektet har en ny katalog fastlane, som inneholder to filer - Appfile og Fastfile. I et nøtteskall lagrer vi tjenestedata i Appfile, og skriver jobber i Fastfile, kalt lanes i Fastlane-terminologi. Jeg anbefaler å lese den offisielle dokumentasjonen: , .
Åpne appfilen i din favoritt tekstredigerer og ta den til følgende skjema:
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
Vi går tilbake til terminalen og i henhold til den offisielle manualen begynner vi å konfigurere match.
$ fastlane match init
$ fastlane match development
Deretter skriver du inn de forespurte dataene - depot, konto, passord, etc.
Det er viktig å: Når du først starter match-verktøyet, vil du bli bedt om å angi et passord for å dekryptere depotet. Det er veldig viktig å lagre dette passordet, vi trenger det når vi setter opp CI-serveren!
En ny fil har dukket opp i fastlane-mappen - Matchfile. Åpne den i favoritttekstredigereren din og vis den slik:
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
Vi fyller det ut akkurat på denne måten hvis vi ønsker å bruke match i fremtiden for å signere builds for visning i Crashlytics og/eller AppStore, det vil si for å signere bunt-ID-en til applikasjonen din.
Men som vi husker laget vi en spesiell jokertegn-ID for å signere testbygget. Åpne derfor Fastfile og gå inn i en ny bane:
lane :testing_build_for_firebase do
match(
type: "development",
readonly: true,
app_identifier: "com.company.*",
git_branch: "uitests" # создаем отдельный бранч для development сертификата для подписи тестовой сборки.
)
end
Lagre og gå inn i terminalen
fastlane testing_build_for_firebaseog vi ser hvordan fastlane opprettet et nytt sertifikat og la det i depotet. Flott!
Åpne XCode. Nå har vi den nødvendige klargjøringsprofilen til skjemaet Match Development com.company.*, som må spesifiseres i Provisioning profile-delen for AmazingApp- og AmazingAppUITests-målene.
Det gjenstår å legge til kjørefelt for monteringstester. La oss gå til et plugin-prosjekt for fastlane som gjør det enklere å sette opp eksport til Firebase Test Lab og følge instruksjonene.
La oss kopiere og lime inn fra det originale eksemplet slik at banetesting_build_for_firebase ender opp med å se slik ut:
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
For fullstendig informasjon om å sette opp fastlane i CircleCI, anbefaler jeg å lese den offisielle dokumentasjonen .
Ikke glem å legge til en ny oppgave til vår 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. Hva med testbenken vår? Konfigurerer Firebase.
La oss komme ned til hva artikkelen ble skrevet for.
Kanskje appen din bruker Firebase på en gratis plan, eller kanskje ikke i det hele tatt. Det er absolutt ingen grunnleggende forskjell, for for testbehov kan vi lage et eget prosjekt med et års gratis bruk (kult, ikke sant?)
Vi logger inn på infrastrukturkontoen vår (eller en hvilken som helst annen, det spiller ingen rolle), og går til . Opprett et nytt prosjekt kalt AmazingAppUITests.
Det er viktig å: I forrige trinn i Fastfile i lane firebase_test_lab_ios_xctest skal gcp_project-parameteren samsvare med prosjektnavnet.
Standardinnstillingene passer oss ganske bra.
Ikke lukk fanen, registrer deg under samme konto i - Dette er et nødvendig tiltak, siden kommunikasjon med Firebase skjer ved hjelp av gcloud-konsollens grensesnitt.
Google gir 300 dollar for et år, som i sammenheng med å utføre autotester tilsvarer et års gratis bruk av tjenesten. Vi legger inn betalingsinformasjonen din, venter på testdebiteringen på $1 og mottar $300 til kontoen din. Etter et år vil prosjektet automatisk overføres til en gratis tariffplan, så det er ingen grunn til å bekymre seg for mulig tap av penger.
La oss gå tilbake til fanen med Firebase-prosjektet og overføre det til Blaze-tariffplanen – nå har vi noe å betale hvis grensen overskrides.
I gcloud-grensesnittet velger du Firebase-prosjektet vårt, velger hovedmenyelementet "Directory" og legger til Cloud Testing API og Cloud Tools Result API.
Gå deretter til menypunktet “IAM og administrasjon” -> Tjenestekontoer -> Opprett tjenestekonto. Vi gir rettigheter til å redigere prosjektet.
Opprett en API-nøkkel i JSON-format
Vi trenger den nedlastede JSON litt senere, men foreløpig vil vi vurdere Test Lab-oppsettet som fullført.
5. Sette opp CircleCI
Et rimelig spørsmål dukker opp - hva skal man gjøre med passord? Den miljøvariable mekanismen til byggemaskinen vår vil hjelpe oss med å lagre passordene våre og andre sensitive data på en sikker måte. I CircleCI-prosjektinnstillingene velger du Miljøvariabler
Og sett opp følgende variabler:
- nøkkel: GOOGLE_APPLICATION_CREDENTIALS
verdi: innholdet i json-filen til gcloud-tjenestens kontonøkkel - nøkkel: MATCH_PASSWORD
verdi: passord for dekryptering av github-depotet med sertifikater - nøkkel: FASTLANE_PASSWORD
verdi: Apple Developer Portal infrastrukturkontopassord
Vi lagrer endringene, oppretter en PR og sender den til teamlederen vår for vurdering.
Resultater av
Som et resultat av disse enkle manipulasjonene fikk vi et godt, stabilt arbeidsstativ med mulighet til å ta opp video på enhetens skjerm på testtidspunktet. I testeksemplet spesifiserte jeg iPhone X-enhetsmodellen, men gården gir et rikt utvalg fra en kombinasjon av forskjellige modeller og iOS-versjoner.
Den andre delen vil bli viet til trinn-for-trinn-oppsett av Firebase Test Lab for et Android-prosjekt.
Kilde: www.habr.com