Jag heter Dmitry, jag arbetar som testare i företaget . Ganska nyligen avslutade jag med ett relativt färskt inslag från — nämligen med instrumentell testning av iOS-applikationer med hjälp av det inbyggda testramverket XCUITest.
Innan detta hade jag redan provat Firebase Test Lab för Android och gillade verkligen allt, så jag bestämde mig för att försöka sätta projektets iOS-testinfrastruktur på samma botten. Jag var tvungen att Googla mycket och allt fungerade inte första gången, så jag bestämde mig för att skriva en handledningsartikel för dem som fortfarande kämpar.
Så om du har UI-tester på ett iOS-projekt kan du redan idag prova att köra dem på riktiga enheter, vänligen tillhandahållna av Good Corporation. För den intresserade, välkommen till katt.
I berättelsen bestämde jag mig för att bygga på några initiala data - ett privat arkiv på GitHub och CircleCI-byggsystemet. Applikationens namn är AmazingApp, bundleID är com.company.amazingapp. Jag presenterar dessa uppgifter omedelbart för att minska efterföljande förvirring.
Om du implementerade vissa lösningar i ditt projekt annorlunda, dela din erfarenhet i kommentarerna.
1. Själva testerna
Skapa en ny projektgren för UI-tester:
$ git checkout develop
$ git pull
$ git checkout -b “feature/add-ui-tests”
Låt oss öppna projektet i XCode och skapa ett nytt mål med UI-tester [XCode -> Arkiv -> Nytt -> Mål -> iOS Testing Bundle], vilket ger det det självförklarande namnet AmazingAppUITests.
Gå till avsnittet Byggfaser i det skapade målet och kontrollera om det finns målberoenden - AmazingApp, i Compile Sources - AmazingAppUITests.swift.
En bra praxis är att dela upp olika byggalternativ i separata system. Vi skapar ett schema för våra UI-tester [XCode -> Produkt -> Schema -> Nytt schema] och ger det samma namn: AmazingAppUITests.
Bygget av det skapade schemat måste inkludera målet för huvudapplikationen - AmazingApp och Target UI-tester - AmazingAppUITests - se skärmdump
Därefter skapar vi en ny byggkonfiguration för UI-tester. I XCode klickar du på projektfilen och går till avsnittet Info. Klicka på "+" och skapa en ny konfiguration, till exempel XCtest. Detta kommer vi att behöva i framtiden för att slippa dansa med tamburin när det gäller kodsignering.
Det finns minst tre mål i ditt projekt: huvudapplikationen, enhetstester (de finns trots allt, eller hur?) och målgränssnittstesterna vi skapade.
Gå till Target AmazingApp, fliken Bygginställningar, Code Signing Identity-avsnittet. För XCtest-konfigurationen, välj iOS Developer. I avsnittet Kodsigneringsstil väljer du Manuell. Vi har inte skapat någon provisioneringsprofil än, men vi kommer definitivt att återkomma till den lite senare.
För Target AmazingAppUITests gör vi samma sak, men i kolumnen Product Bundle Identifier anger vi com.company.amazingappuitests.
2. Konfigurera ett projekt i Apple Developer Program
Gå till sidan för Apple Developer Program, gå till avsnittet Certificates, Identifiers & Profiles och sedan till kolumnen App IDs i objektet Identifiers. Skapa ett nytt app-ID som heter AmazingAppUITests och bundleID com.company.amazingappuitests.
Nu har vi möjlighet att signera våra tester med ett separat certifikat, men... Proceduren för att montera en build för testning innebär att man monterar själva applikationen och monterar testlöparen. Följaktligen står vi inför problemet med att signera två paket-ID:n med en provisioneringsprofil. Lyckligtvis finns det en enkel och elegant lösning - Wildcard App ID. Vi upprepar proceduren för att skapa ett nytt app-ID, men istället för explicit app-ID väljer du Wildcard-app-ID som på skärmdumpen.
Vid det här laget har vi arbetat klart med developer.apple.com, men vi kommer inte att minimera webbläsarfönstret. Låt oss gå till och läs om Match-verktyget från pärm till pärm.
En uppmärksam läsare märkte att för att använda det här verktyget behöver vi ett privat arkiv och ett konto med tillgång till både Apples utvecklarprogram och Github. Vi skapar (om det plötsligt inte finns något sådant) en redogörelse för formen [e-postskyddad], kom med ett starkt lösenord, registrera det hos developer.apple.com och utse det till projektadministratör. Därefter ger vi kontot tillgång till ditt företags github-förråd och skapar ett nytt privat förråd med ett namn som AmazingAppMatch.
3. Ställa in Fastlane och matchverktyget
Öppna en terminal, gå till mappen med projektet och initiera fastlane som anges i . Efter att ha angett kommandot
$ fastlane initDu kommer att bli ombedd att välja tillgängliga användningskonfigurationer. Välj det fjärde alternativet - manuell projektinställning.
Projektet har en ny katalog fastlane, som innehåller två filer - Appfile och Fastfile. I ett nötskal lagrar vi tjänstedata i Appfile och skriver jobb i Fastfile, kallade lanes i Fastlane-terminologi. Jag rekommenderar att du läser den officiella dokumentationen: , .
Öppna Appfilen i din favorittextredigerare och ta den till följande formulär:
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 återvänder till terminalen och enligt den officiella manualen börjar vi konfigurera match.
$ fastlane match init
$ fastlane match development
Ange sedan de begärda uppgifterna - arkiv, konto, lösenord, etc.
Viktigt: När du först startar matchningsverktyget kommer du att bli ombedd att ange ett lösenord för att dekryptera förvaret. Det är mycket viktigt att spara detta lösenord, vi kommer att behöva det när vi konfigurerar CI-servern!
En ny fil har dykt upp i fastlane-mappen - Matchfile. Öppna den i din favorittextredigerare och visa den så här:
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 i det exakt så här om vi vill använda matchning i framtiden för att signera builds för visning i Crashlytics och/eller AppStore, det vill säga för att signera paket-ID:t för din applikation.
Men som vi minns skapade vi ett speciellt Wildcard-ID för att signera testbygget. Öppna därför Fastfile och ange en ny fil:
lane :testing_build_for_firebase do
match(
type: "development",
readonly: true,
app_identifier: "com.company.*",
git_branch: "uitests" # создаем отдельный бранч для development сертификата для подписи тестовой сборки.
)
end
Spara och gå in i terminalen
fastlane testing_build_for_firebaseoch vi ser hur fastlane skapade ett nytt certifikat och placerade det i förvaret. Bra!
Öppna XCode. Nu har vi den nödvändiga provisioneringsprofilen för formuläret Match Development com.company.*, som måste anges i avsnittet Provisioning profile för AmazingApp- och AmazingAppUITests-målen.
Det återstår att lägga till körfält för monteringstester. Låt oss gå till ett plugin-projekt för fastlane som gör det enklare att ställa in export till Firebase Test Lab och följa instruktionerna.
Låt oss kopiera och klistra in från originalexemplet så att vår lane testing_build_for_firebase ser ut så här:
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
För fullständig information om hur du ställer in fastlane i CircleCI rekommenderar jag att du läser den officiella dokumentationen .
Glöm inte att lägga till en ny uppgift till 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. Hur är det med vår testbänk? Konfigurera Firebase.
Låt oss gå ner till vad artikeln skrevs för.
Kanske använder din app Firebase på en gratis plan, eller kanske inte alls. Det finns absolut ingen grundläggande skillnad, för för testbehov kan vi skapa ett separat projekt med ett års gratis användning (cool, eller hur?)
Vi loggar in på vårt infrastrukturkonto (eller något annat, det spelar ingen roll) och går till . Skapa ett nytt projekt med namnet AmazingAppUITests.
Viktigt: I föregående steg i snabbfilen i fil firebase_test_lab_ios_xctest ska parametern gcp_project matcha projektnamnet.
Standardinställningarna passar oss ganska bra.
Stäng inte fliken, registrera dig under samma konto i - detta är en nödvändig åtgärd, eftersom kommunikation med Firebase sker via gcloud-konsolens gränssnitt.
Google ger $300 för ett år, vilket i samband med att utföra autotester motsvarar ett års gratis användning av tjänsten. Vi anger din betalningsinformation, väntar på testdebiteringen på 1 USD och får 300 USD till ditt konto. Efter ett år kommer projektet automatiskt att överföras till en gratis tariffplan, så det finns ingen anledning att oroa sig för eventuell förlust av pengar.
Låt oss återgå till fliken med Firebase-projektet och överföra det till Blaze-tariffplanen – nu har vi något att betala om gränsen överskrids.
I gcloud-gränssnittet väljer du vårt Firebase-projekt, väljer huvudmenyalternativet "Directory" och lägger till Cloud Testing API och Cloud Tools Result API.
Gå sedan till menypunkten “IAM och administration” -> Servicekonton -> Skapa servicekonto. Vi beviljar rättigheter att redigera projektet.
Skapa en API-nyckel i JSON-format
Vi kommer att behöva den nedladdade JSON lite senare, men för tillfället kommer vi att överväga att testlabbinstallationen är klar.
5. Ställa in CircleCI
En rimlig fråga uppstår - vad ska man göra med lösenord? Miljövariabelmekanismen i vår byggmaskin hjälper oss att säkert lagra våra lösenord och annan känslig data. I CircleCI-projektets inställningar väljer du Miljövariabler
Och ställ in följande variabler:
- nyckel: GOOGLE_APPLICATION_CREDENTIALS
värde: innehållet i json-filen för gcloud-tjänstens kontonyckel - nyckel: MATCH_PASSWORD
värde: lösenord för att dekryptera github-förvaret med certifikat - nyckel: FASTLANE_PASSWORD
värde: Apple Developer Portal infrastrukturkonto lösenord
Vi sparar ändringarna, skapar en PR och skickar den till vår teamledare för granskning.
Resultat av
Som ett resultat av dessa enkla manipulationer fick vi ett bra, stabilt arbetsställ med möjlighet att spela in video på enhetens skärm vid testtillfället. I testexemplet angav jag enhetsmodellen iPhone X, men gården erbjuder ett rikt urval från en kombination av olika modeller och iOS-versioner.
Den andra delen kommer att ägnas åt steg-för-steg installation av Firebase Test Lab för ett Android-projekt.
Källa: will.com