Mit navn er Dmitry, jeg arbejder som tester i virksomheden . For ganske nylig blev jeg færdig med at beskæftige mig med et relativt nyligt indslag fra — nemlig med instrumentel test af iOS-applikationer ved hjælp af den native testramme XCUITest.
Før dette havde jeg allerede prøvet Firebase Test Lab til Android og kunne virkelig godt lide alt, så jeg besluttede at prøve at sætte projektets iOS-testinfrastruktur på samme fod. Jeg var nødt til at Google meget, og alt fungerede ikke første gang, så jeg besluttede at skrive en tutorial-artikel til dem, der stadig kæmper.
Så hvis du har UI-tests på et iOS-projekt, kan du allerede prøve at køre dem på rigtige enheder i dag, venligst leveret af Good Corporation. For interesserede, velkommen til kat.
I historien besluttede jeg at bygge på nogle indledende data - et privat depot på GitHub og CircleCI-byggesystemet. Applikationens navn er AmazingApp, bundleID er com.company.amazingapp. Jeg præsenterer disse data med det samme for at reducere efterfølgende forvirring.
Hvis du implementerede visse løsninger i dit projekt anderledes, så del din oplevelse i kommentarerne.
1. Selve testene
Opret en ny projektgren til UI-test:
$ git checkout develop
$ git pull
$ git checkout -b “feature/add-ui-tests”
Lad os åbne projektet i XCode og oprette et nyt mål med UI-tests [XCode -> Fil -> Nyt -> Target -> iOS-testpakke], hvilket giver det det selvforklarende navn AmazingAppUITests.
Gå til sektionen Build Phases i det oprettede Target og tjek for tilstedeværelsen af Target Dependencies - AmazingApp, i Compile Sources - AmazingAppUITests.swift.
En god praksis er at adskille forskellige byggemuligheder i separate ordninger. Vi opretter et skema for vores UI-tests [XCode -> Produkt -> Skema -> Nyt skema] og giver det samme navn: AmazingAppUITests.
Opbygningen af det oprettede skema skal omfatte målet for hovedapplikationen - AmazingApp og Target UI-tests - AmazingAppUITests - se skærmbillede
Dernæst opretter vi en ny build-konfiguration til UI-tests. I XCode skal du klikke på projektfilen og gå til Info-sektionen. Klik på “+” og opret en ny konfiguration, for eksempel XCtest. Det får vi brug for i fremtiden for at undgå at danse med en tamburin, når det kommer til kodesignering.
Der er mindst tre Targets i dit projekt: Hovedapplikationen, enhedstests (de findes trods alt, ikke?) og Target UI-testene, vi oprettede.
Gå til Target AmazingApp, Build Settings fanen, Code Signing Identity sektionen. For XCtest-konfigurationen skal du vælge iOS Developer. I sektionen Code Signing Style skal du vælge Manual. Vi har ikke genereret en klargøringsprofil endnu, men vi vender helt sikkert tilbage til den lidt senere.
For Target AmazingAppUITests gør vi det samme, men i kolonnen Product Bundle Identifier indtaster vi com.company.amazingappuitests.
2. Opsætning af et projekt i Apple Developer Program
Gå til Apple Developer Program-siden, gå til sektionen Certifikater, id'er og profiler og derefter til kolonnen App-id'er i punktet Identifikatorer. Opret et nyt app-id kaldet AmazingAppUITests og bundleID com.company.amazingappuitests.
Nu har vi mulighed for at signere vores tests med et separat certifikat, men... Proceduren for at samle en build til test går ud på at samle selve applikationen og samle testløberen. Derfor står vi over for problemet med at underskrive to bundt-id'er med én klargøringsprofil. Heldigvis findes der en enkel og elegant løsning - Wildcard App ID. Vi gentager proceduren for at oprette et nyt app-id, men i stedet for eksplicit app-id skal du vælge Wildcard-app-id som på skærmbilledet.
På dette tidspunkt er vi færdige med at arbejde med developer.apple.com, men vi vil ikke minimere browservinduet. Lad os gå til og læs om Match-værktøjet fra ende til anden.
En opmærksom læser bemærkede, at for at bruge dette værktøj har vi brug for et privat depot og en konto med adgang til både Apple Developer Program og Github. Vi opretter (hvis der pludselig ikke er sådan noget) en konto for formen [e-mail beskyttet], kom med en stærk adgangskode, registrer den hos developer.apple.com, og udnævn den som projektadministrator. Dernæst giver vi kontoen adgang til din virksomheds github-depot og opretter et nyt privat depot med et navn som AmazingAppMatch.
3. Opsætning af Fastlane og match-værktøjet
Åbn en terminal, gå til mappen med projektet og initialiser fastlane som angivet i . Efter at have indtastet kommandoen
$ fastlane initDu vil blive bedt om at vælge tilgængelige brugskonfigurationer. Vælg den fjerde mulighed - manuel projektopsætning.
Projektet har en ny mappe fastlane, som indeholder to filer - Appfile og Fastfile. I en nøddeskal gemmer vi servicedata i Appfile og skriver jobs i Fastfile, kaldet baner i Fastlane-terminologi. Jeg anbefaler at læse den officielle dokumentation: , .
Åbn App-filen i din foretrukne teksteditor, og bring den til følgende 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
Vi vender tilbage til terminalen og i henhold til den officielle manual begynder vi at konfigurere match.
$ fastlane match init
$ fastlane match development
Indtast derefter de ønskede data - lager, konto, adgangskode osv.
Vigtigt: Når du først starter match-værktøjet, bliver du bedt om at indtaste en adgangskode for at dekryptere lageret. Det er meget vigtigt at gemme denne adgangskode, vi skal bruge den, når vi opsætter CI-serveren!
En ny fil er dukket op i fastlane-mappen - Matchfile. Åbn det i din foretrukne teksteditor og vis det sådan her:
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 udfylder det præcis på denne måde, hvis vi ønsker at bruge match i fremtiden til at signere builds til visning i Crashlytics og/eller AppStore, det vil sige til at underskrive bundle-id'et for din applikation.
Men som vi husker, oprettede vi et særligt Wildcard-id for at underskrive testbuilden. Åbn derfor Fastfile og indtast en ny bane:
lane :testing_build_for_firebase do
match(
type: "development",
readonly: true,
app_identifier: "com.company.*",
git_branch: "uitests" # создаем отдельный бранч для development сертификата для подписи тестовой сборки.
)
end
Gem og gå ind i terminalen
fastlane testing_build_for_firebaseog vi ser, hvordan fastlane oprettede et nyt certifikat og lagde det i repository. Store!
Åbn XCode. Nu har vi den nødvendige provisioneringsprofil af formularen Match Development com.company.*, som skal specificeres i Provisioning profile sektionen for AmazingApp- og AmazingAppUITests-målene.
Det er tilbage at tilføje bane til monteringstest. Lad os gå til et plugin-projekt til fastlane, der gør det nemmere at opsætte eksport til Firebase Test Lab og følge instruktionerne.
Lad os kopiere og indsætte fra det originale eksempel, så vores banetest_build_for_firebase ender med at se sådan ud:
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 fuldstændig information om opsætning af fastlane i CircleCI, anbefaler jeg at læse den officielle dokumentation .
Glem ikke at tilføje en ny opgave til vores 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. Hvad med vores testbænk? Opsætning af Firebase.
Lad os komme ned til, hvad artiklen er skrevet til.
Måske bruger din app Firebase på en gratis plan, eller måske slet ikke. Der er absolut ingen grundlæggende forskel, for til testbehov kan vi oprette et separat projekt med et års gratis brug (fedt, ikke?)
Vi logger ind på vores infrastrukturkonto (eller en hvilken som helst anden, det gør ikke noget), og går til . Opret et nyt projekt ved navn AmazingAppUITests.
Vigtigt: I det forrige trin i Fastfilen i bane firebase_test_lab_ios_xctest skal gcp_project-parameteren matche projektnavnet.
Standardindstillingerne passer os ret godt.
Luk ikke fanen, tilmeld dig under samme konto i - dette er en nødvendig foranstaltning, da kommunikation med Firebase sker ved hjælp af gcloud-konsollens grænseflade.
Google giver 300 dollars for et år, hvilket i forbindelse med udførelse af autotest svarer til et års gratis brug af tjenesten. Vi indtaster dine betalingsoplysninger, venter på testdebiteringen på $1 og modtager $300 til din konto. Efter et år vil projektet automatisk blive overført til en gratis takstplan, så der er ingen grund til at bekymre sig om et eventuelt pengetab.
Lad os vende tilbage til fanen med Firebase-projektet og overføre det til Blaze-takstplanen - nu har vi noget at betale, hvis grænsen overskrides.
I gcloud-grænsefladen skal du vælge vores Firebase-projekt, vælge hovedmenupunktet "Directory" og tilføje Cloud Testing API og Cloud Tools Result API.
Gå derefter til menupunktet “IAM og administration” -> Servicekonti -> Opret servicekonto. Vi giver rettigheder til at redigere projektet.
Opret en API-nøgle i JSON-format
Vi får brug for den downloadede JSON lidt senere, men indtil videre vil vi betragte Test Lab-opsætningen som færdig.
5. Opsætning af CircleCI
Et rimeligt spørgsmål opstår - hvad skal man gøre med adgangskoder? Den miljøvariable mekanisme i vores byggemaskine hjælper os med at opbevare vores adgangskoder og andre følsomme data sikkert. I CircleCI-projektindstillingerne skal du vælge Miljøvariabler
Og opsæt følgende variable:
- nøgle: GOOGLE_APPLICATION_CREDENTIALS
værdi: indholdet af json-filen for gcloud-tjenestens kontonøgle - nøgle: MATCH_PASSWORD
værdi: adgangskode til dekryptering af github-lageret med certifikater - nøgle: FASTLANE_PASSWORD
værdi: Adgangskode til Apple Developer Portal-infrastrukturkonto
Vi gemmer ændringerne, opretter en PR og sender den til vores teamleder til gennemgang.
Resultaterne af
Som et resultat af disse simple manipulationer modtog vi en god, stabil arbejdsstand med mulighed for at optage video på enhedens skærm på testtidspunktet. I testeksemplet specificerede jeg iPhone X-enhedsmodellen, men gården giver et rigt udvalg fra en kombination af forskellige modeller og iOS-versioner.
Den anden del vil blive afsat til trin-for-trin opsætning af Firebase Test Lab til et Android-projekt.
Kilde: www.habr.com