Mijn naam is Dmitry, ik werk als tester in het bedrijf . Vrij recentelijk ben ik klaar met het omgaan met een relatief recente functie van — namelijk met het instrumenteel testen van iOS-applicaties met behulp van het native testframework XCUITest.
Voordien had ik Firebase Test Lab voor Android al geprobeerd en vond alles erg leuk, dus besloot ik te proberen de iOS-testinfrastructuur van het project op dezelfde voet te plaatsen. Ik moest veel Googlen en niet alles lukte de eerste keer, dus besloot ik een tutorialartikel te schrijven voor degenen die het nog steeds moeilijk hebben.
Dus als u UI-tests heeft voor een iOS-project, kunt u deze vandaag al op echte apparaten proberen uit te voeren, vriendelijk aangeboden door Good Corporation. Voor geïnteresseerden: welkom bij cat.
In het verhaal besloot ik voort te bouwen op enkele initiële gegevens: een privérepository op GitHub en het CircleCI-bouwsysteem. De applicatienaam is AmazingApp, bundelID is com.company.amazingapp. Ik presenteer deze gegevens onmiddellijk om latere verwarring te verminderen.
Als u bepaalde oplossingen in uw project anders heeft geïmplementeerd, deel dan uw ervaringen in de opmerkingen.
1. De tests zelf
Maak een nieuwe projectvertakking voor UI-tests:
$ git checkout develop
$ git pull
$ git checkout -b “feature/add-ui-tests”
Laten we het project openen in XCode en een nieuw doel maken met UI-tests [XCode -> Bestand -> Nieuw -> Doel -> iOS-testbundel], waarbij we het de voor zichzelf sprekende naam AmazingAppUITests geven.
Ga naar de sectie Bouwfasen van het gemaakte doel en controleer op de aanwezigheid van doelafhankelijkheden - AmazingApp, in Compile Sources - AmazingAppUITests.swift.
Een goede praktijk is om verschillende bouwopties in afzonderlijke schema's te scheiden. We maken een schema voor onze UI-tests [XCode -> Product -> Schema -> Nieuw schema] en geven het dezelfde naam: AmazingAppUITests.
De build van het gemaakte schema moet het doel van de hoofdapplicatie bevatten - AmazingApp en Target UI-tests - AmazingAppUITests - zie screenshot
Vervolgens maken we een nieuwe build-configuratie voor UI-tests. Klik in XCode op het projectbestand en ga naar het gedeelte Info. Klik op “+” en maak een nieuwe configuratie aan, bijvoorbeeld XCtest. Dit zullen we in de toekomst nodig hebben om te voorkomen dat we met een tamboerijn moeten dansen als het gaat om het ondertekenen van codes.
Er zijn minstens drie Targets in uw project: de hoofdapplicatie, unit-tests (ze bestaan tenslotte, toch?) en de Target UI-tests die we hebben gemaakt.
Ga naar Target AmazingApp, tabblad Build-instellingen, sectie Code Signing Identity. Voor de XCtest-configuratie selecteert u iOS Developer. Selecteer Handmatig in de sectie Stijl voor codeondertekening. We hebben nog geen voorzieningenprofiel gegenereerd, maar we komen er later zeker op terug.
Voor Target AmazingAppUITests doen we hetzelfde, maar in de kolom Product Bundle Identifier voeren we com.company.amazingappuitests in.
2. Een project opzetten in het Apple Developer Program
Ga naar de Apple Developer Program-pagina, ga naar de sectie Certificaten, Identifiers & Profiles en vervolgens naar de kolom App-ID's van het item Identifiers. Maak een nieuwe app-ID met de naam AmazingAppUITests en bundelID com.company.amazingappuitests.
Nu hebben we de mogelijkheid om onze tests te ondertekenen met een apart certificaat, maar... De procedure voor het samenstellen van een build voor testen omvat het assembleren van de applicatie zelf en het assembleren van de testrunner. Dienovereenkomstig worden we geconfronteerd met het probleem van het ondertekenen van twee bundel-ID's met één voorzieningenprofiel. Gelukkig is er een eenvoudige en elegante oplossing: Wildcard App ID. We herhalen de procedure voor het maken van een nieuwe app-ID, maar in plaats van de expliciete app-ID selecteert u Wildcard-app-ID zoals in de schermafbeelding.
Op dit moment zijn we klaar met het werken met developer.apple.com, maar we zullen het browservenster niet minimaliseren. Laten we gaan naar en lees over het Match-hulpprogramma van begin tot eind.
Een oplettende lezer merkte op dat we om dit hulpprogramma te gebruiken een privérepository en een account nodig hebben met toegang tot zowel het Apple Developer Program als Github. We maken (als er ineens niet zoiets bestaat) een account van het formulier [e-mail beveiligd], bedenk een sterk wachtwoord, registreer het bij developer.apple.com en stel het in als projectbeheerder. Vervolgens geven we het account toegang tot de github-repository van uw bedrijf en creëren we een nieuwe privérepository met een naam als AmazingAppMatch.
3. Fastlane en het matchhulpprogramma instellen
Open een terminal, ga naar de map met het project en initialiseer fastlane zoals aangegeven in . Na het invoeren van de opdracht
$ fastlane initU wordt gevraagd de beschikbare gebruiksconfiguraties te selecteren. Selecteer de vierde optie: handmatige projectconfiguratie.
Het project heeft een nieuwe directory fastlane, die twee bestanden bevat: Appfile en Fastfile. Kort gezegd slaan we servicegegevens op in Appfile en schrijven we taken in Fastfile, in Fastlane-terminologie lanes genoemd. Ik raad aan de officiële documentatie te lezen: , .
Open het appbestand in uw favoriete teksteditor en breng het naar het volgende formulier:
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
We keren terug naar de terminal en volgens de officiële handleiding beginnen we de match te configureren.
$ fastlane match init
$ fastlane match development
Voer vervolgens de gevraagde gegevens in: repository, account, wachtwoord, enz.
Belangrijk: Wanneer u het matchhulpprogramma voor het eerst start, wordt u gevraagd een wachtwoord in te voeren om de repository te decoderen. Het is erg belangrijk om dit wachtwoord op te slaan; we hebben het nodig bij het instellen van de CI-server!
Er is een nieuw bestand verschenen in de fastlane-map: Matchfile. Open het in uw favoriete teksteditor en geef het als volgt weer:
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
We vullen het precies zo in als we match in de toekomst willen gebruiken om builds te ondertekenen voor plaatsing in Crashlytics en/of AppStore, dat wil zeggen om de bundel-ID van uw applicatie te ondertekenen.
Maar zoals we ons herinneren, hebben we een speciale Wildcard-ID gemaakt om de testbuild te ondertekenen. Open daarom Fastfile en voer een nieuwe rijstrook in:
lane :testing_build_for_firebase do
match(
type: "development",
readonly: true,
app_identifier: "com.company.*",
git_branch: "uitests" # создаем отдельный бранч для development сертификата для подписи тестовой сборки.
)
end
Opslaan en invoeren in de terminal
fastlane testing_build_for_firebaseen we zien hoe fastlane een nieuw certificaat heeft gemaakt en in de repository heeft geplaatst. Geweldig!
Open XCode. Nu hebben we het benodigde provisioningprofiel van het formulier Match Development com.company.*, dat moet worden gespecificeerd in de sectie Provisioning profile voor de doelen AmazingApp en AmazingAppUITests.
Er moet nog een rijstrook worden toegevoegd voor het samenstellen van tests. Laten we gaan naar een plug-inproject voor fastlane dat het eenvoudiger maakt om de export naar Firebase Test Lab in te stellen en de instructies te volgen.
Laten we het originele voorbeeld kopiëren en plakken, zodat onze lane testing_build_for_firebase er als volgt uitziet:
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
Voor volledige informatie over het instellen van fastlane in CircleCI raad ik aan de officiële documentatie te lezen .
Vergeet niet een nieuwe taak toe te voegen aan onze 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. Hoe zit het met onze testbank? Firebase instellen.
Laten we eens kijken waarvoor het artikel is geschreven.
Misschien gebruikt uw app Firebase met een gratis abonnement, of misschien helemaal niet. Er is absoluut geen fundamenteel verschil, want voor testbehoeften kunnen we een apart project maken met een jaar gratis gebruik (cool, toch?)
We loggen in op ons infrastructuuraccount (of een ander, het maakt niet uit) en gaan naar . Maak een nieuw project met de naam AmazingAppUITests.
Belangrijk: In de vorige stap in de Fastfile in lane firebase_test_lab_ios_xctest moet de parameter gcp_project overeenkomen met de projectnaam.
De standaardinstellingen bevallen ons prima.
Sluit het tabblad niet, registreer u onder hetzelfde account in - dit is een noodzakelijke maatregel, omdat de communicatie met Firebase plaatsvindt via de gcloud-console-interface.
Google geeft 300 dollar voor een jaar, wat in het kader van het uitvoeren van autotests gelijk staat aan een jaar gratis gebruik van de dienst. We voeren uw betalingsgegevens in, wachten op de testafschrijving van $ 1 en ontvangen $ 300 op uw rekening. Na een jaar wordt het project automatisch overgezet naar een gratis tariefplan, zodat u zich geen zorgen hoeft te maken over mogelijk geldverlies.
Laten we terugkeren naar het tabblad met het Firebase-project en het overbrengen naar het Blaze-tariefplan - nu hebben we iets te betalen als de limiet wordt overschreden.
Selecteer in de gcloud-interface ons Firebase-project, selecteer het hoofdmenu-item “Directory” en voeg de Cloud Testing API en Cloud Tools Result API toe.
Ga vervolgens naar het menu-item “IAM en administratie” -> Serviceaccounts -> Serviceaccount aanmaken. Wij verlenen rechten om het project te bewerken.
Maak een API-sleutel in JSON-indeling
We hebben de gedownloade JSON iets later nodig, maar voorlopig beschouwen we de installatie van het Test Lab als voltooid.
5. CircleCI instellen
Er rijst een redelijke vraag: wat te doen met wachtwoorden? Het omgevingsvariabele mechanisme van onze bouwmachine helpt ons onze wachtwoorden en andere gevoelige gegevens veilig op te slaan. Selecteer Omgevingsvariabelen in de CircleCI-projectinstellingen
En stel de volgende variabelen in:
- sleutel: GOOGLE_APPLICATION_CREDENTIALS
waarde: inhoud van het json-bestand van de gcloud-serviceaccountsleutel - sleutel: MATCH_PASSWORD
waarde: wachtwoord voor het decoderen van de github-repository met certificaten - sleutel: FASTLANE_PASSWORD
waarde: wachtwoord voor Apple Developer Portal-infrastructuuraccount
We slaan de wijzigingen op, maken een PR en sturen deze ter beoordeling naar onze teamleider.
Resultaten van
Als resultaat van deze eenvoudige manipulaties kregen we een goede, stabiele werkstandaard met de mogelijkheid om video op te nemen op het scherm van het apparaat tijdens het testen. In het testvoorbeeld heb ik het iPhone X-apparaatmodel gespecificeerd, maar de farm biedt een rijke selectie uit een combinatie van verschillende modellen en iOS-versies.
Het tweede deel zal gewijd zijn aan de stapsgewijze installatie van Firebase Test Lab voor een Android-project.
Bron: www.habr.com