Mijn naam is Dmitry, ik werk als tester bij het bedrijf . Onlangs ben ik bezig geweest met een relatief nieuwe functie van — specifiek, met instrumentatie testen van iOS-applicaties met behulp van het native testframework XCUITest.
Eerder heb ik al Firebase Test Lab voor Android geprobeerd en vond het geweldig, dus besloot ik mijn testinfrastructuur voor het iOS-project op dezelfde rails te zetten. Ik moest veel googelen en niet alles lukte de eerste keer, daarom besloot ik een tutorial te schrijven voor degenen die dit nog moeten doen.
Dus, als je UI-tests voor je iOS-project hebt, kun je vandaag nog proberen deze uit te voeren op echte apparaten, vriendelijk aangeboden door de Corporation of Good. Geïnteresseerden — welkom onder de kap.
In dit verhaal besloot ik uit te gaan van enkele gegevens — een privé-repository op GitHub en het build-systeem CircleCI. De naam van de applicatie is AmazingApp, bundleID — com.company.amazingapp. Deze gegevens geef ik meteen, om verwarring later te verminderen.
Als je bepaalde oplossingen in je project anders hebt geïmplementeerd — deel je ervaringen in de reacties.
1. De tests zelf
Maak een nieuwe tak van het project voor UI-tests:
$ git checkout develop
$ git pull
$ git checkout -b "feature/add-ui-tests"
Laten we het project in XCode openen en een nieuw doel (Target) creëren voor UI-tests [XCode -> File -> New -> Target -> iOS Testing Bundle], geef het een begrijpelijke naam: AmazingAppUITests.
Ga naar de sectie Build Phases van het gemaakte Target en controleer of de Target Dependencies — AmazingApp, in Compile Sources — AmazingAppUITests.swift aanwezig is.
Het is een goede praktijk om verschillende buildvarianten in aparte Schemes onder te brengen. Laten we een schema maken voor onze UI-tests [XCode -> Product -> Scheme -> New Scheme] en geven het dezelfde naam: AmazingAppUITests.
De build van het gemaakte schema moet de Target van de hoofdapplicatie — AmazingApp en de Target UI-tests — AmazingAppUITests bevatten — zie screenshot.
Vervolgens maken we een nieuwe buildconfiguratie voor de UI-tests. In XCode klikken we op het projectbestand, gaan naar de sectie Info. Klik op “+” en maak een nieuwe configuratie aan, bijvoorbeeld XCtest. Dit is nodig voor wanneer we met code signing bezig zijn, om gedoe te voorkomen.
In je project zijn er minstens drie Targets: de hoofdapplicatie, unit tests (die zijn er toch, nietwaar?) en de door ons gemaakte Target UI-tests.
We go to Target AmazingApp, tab Build Settings, section Code Signing Identity. For the XCtest configuration, we select iOS Developer. In the Code Signing Style section, we choose Manual. We have not yet generated a provisioning profile, but we will definitely return to it a bit later.
For Target AmazingAppUITests, we do the same, but in the Product Bundle Identifier field, we enter com.company.amazingappuitests.
2. Setting Up the Project in Apple Developer Program
We go to the Apple Developer Program page, navigate to the Certificates, Identifiers & Profiles section, and then to the App IDs field under Identifiers. We create a new App ID named AmazingAppUITests with bundleID com.company.amazingappuitests.
Now we have the opportunity to sign our tests with a separate certificate, but... The build assembly procedure for testing involves building the application itself and the test runner builds. Accordingly, we encounter the issue of signing two bundle IDs with one provisioning profile. Fortunately, there is a simple and elegant solution — Wildcard App ID. We repeat the procedure of creating a new App ID, but instead of Explicit App ID, we select Wildcard App ID as shown in the screenshot.
At this stage, our work with developer.apple.com is over, but we won't close the browser window. We head to and read about the Match utility from cover to cover.
The attentive reader noticed that to use this utility, we will need a private repository and an account that has access to both the Apple Developer Program and GitHub. We create (if there isn't one) an account like InfrastructureAccount@your.company.domain, come up with a strong password, register it at developer.apple.com, and appoint it as the project administrator. Next, we give the account access to your company's GitHub repository and create a new private repository named something like AmazingAppMatch.
3. Configuring Fastlane and the Match Utility
We open the terminal, go to the project folder, and initialize Fastlane as specified in the . After entering the command
$ fastlane inityou will be prompted to select available usage configurations. We choose the fourth option — manual project setup.
A new directory fastlane has appeared in the project, containing two files — Appfile and Fastfile. In brief — we store service data in Appfile, and we write jobs, referred to as lanes in Fastlane terminology, in Fastfile. I recommend reading the official documentation: , .
We open Appfile in our favorite text editor and modify it to look like this:
app_identifier "com.company.amazingapp" # Bundel-ID
apple_dev_portal_id "infrastructureaccount@your.company.domain" # Gemaakt infrastructuuraccount met rechten om iOS-project te bewerken in het Apple Developer Program.
team_id "LSDY3IFJAY9" # Jouw Developer Portal Team-ID
We keren terug naar de terminal en beginnen met het configureren van match volgens de officiële handleiding.
$ fastlane match init
$ fastlane match development
Voer de gevraagde gegevens in — repository, account, wachtwoord, enzovoort.
Belangrijk: Bij de eerste uitvoering zal de match-tool je vragen om het wachtwoord voor het decrypten van de repository in te voeren. Het is van cruciaal belang om dit wachtwoord te bewaren; het zal van pas komen tijdens het configureren van de CI-server!
Er is een nieuw bestand genaamd Matchfile in de fastlane-map verschenen. Open het in je favoriete teksteditor en breng het in de juiste vorm:
git_url("https://github.com/YourCompany/AmazingAppMatch") #Gemaakt privé-repository voor het opslaan van certificaten en profielsen.
type("development") # Het standaardtype, kan zijn: appstore, adhoc, enterprise of development
app_identifier("com.company.amazingapp")
username("infrastructureaccount@your.company.domain") # Jouw infrastructuuraccount Apple Developer Portal gebruikersnaam
Vul het op deze manier in, als we in de toekomst match willen gebruiken voor het ondertekenen van builds voor uitgave in Crashlytics en/of de App Store, d.w.z. voor het ondertekenen van de bundel-ID van jouw applicatie.
Maar, zoals we ons herinneren, hebben we een speciale Wildcard-ID aangemaakt voor de ondertekening van de testbuild. Daarom openen we het Fastfile en voegen we een nieuwe lane toe:
lane :testing_build_for_firebase do
match(
type: "development",
readonly: true,
app_identifier: "com.company.*",
git_branch: "uitests" # we maken een aparte branch voor het development-certificaat voor het ondertekenen van de testbuild.
)
end
Sla op, voer in de terminal in
fastlane testing_build_for_firebaseen zie hoe fastlane een nieuw certificaat heeft aangemaakt en het in de repository heeft geplaatst. Geweldig!
We openen XCode. Nu hebben we het juiste provisioning-profiel in de vorm van Match Development com.company.*, dat moet worden opgegeven in de sectie Provisioning-profiel voor de targets AmazingApp en AmazingAppUITests.
Nu moeten we de lane voor het bouwen van testen aanvullen. Laten we naar het project van de plugin voor fastlane gaan, dat het instellen van de export naar Firebase Test Lab vergemakkelijkt, en de instructies volgen.
Kopieer en plak uit het originele voorbeeld, zodat onze lane testing_build_for_firebase er uiteindelijk zo 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 (hier komen we later op terug)
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 ons config.yml aan te vullen met een nieuwe taak:
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 # afhankelijkheden bijwerken
- run:
name: install gcloud-sdk # gcloud moet op de mac worden geïnstalleerd
command: |
ruby -e "$(curl -fsSL https:\/\/raw.githubusercontent.com\/Homebrew\/install\/master\/install)" \/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 # start de build lane en stuur naar firebase
4. Wat doen we met onze testomgeving? Laten we Firebase instellen.
Laten we nu beginnen met hetgeen waar dit artikel om draait.
Misschien gebruikt je app Firebase op een gratis abonnement, misschien ook helemaal niet. Het maakt niet uit, want voor testdoeleinden kunnen we een apart project aanmaken met een jaar gratis gebruik (geweldig, toch?)
Log in op ons infrastructuuraccount (of een ander, dat doet er niet toe) en ga naar . Maak een nieuw project aan met de naam AmazingAppUITests.
Belangrijk: In de vorige stap moet de parameter gcp_project in het Fastfile voor lane firebase_test_lab_ios_xctest overeenkomen met de naam van het project.
De standaardinstellingen zijn voor ons prima.
Sluit het tabblad niet, registreer je met hetzelfde account in — dit is een noodzakelijke stap, aangezien de communicatie met Firebase gebeurt via de gcloud-console interface.
Google biedt $300 voor een jaar, wat in de context van geautomatiseerde tests gelijk staat aan een jaar gratis gebruik van de service. We voeren betalingsgegevens in, wachten op de testafschrijving van $1 en krijgen $300 op onze rekening. Na een jaar zal het project automatisch worden overgezet naar het gratis tarief, dus maak je geen zorgen over mogelijke verlies van geld.
Laten we teruggaan naar het tabblad met het Firebase-project en het overzetten naar het Blaze-tariefplan — nu hebben we middelen om te betalen in geval van overschrijding van de limiet.
In de gcloud-interface selecteren we ons Firebase-project, kiezen we de optie in het hoofdmenu 'Catalogus' en voegen we de Cloud Testing API en de Cloud Tools Result API toe.
Vervolgens gaan we naar het menu 'IAM en administratie' -> Serviceaccounts -> Maak een serviceaccount aan. We geven bewerkingsrechten op het project.
We genereren een API-sleutel in JSON-formaat
De gedownloade JSON hebben we iets later nodig, maar voor nu beschouwen we de configuratie van Test Lab als voltooid.
5. Instelling van CircleCI
Er rijst een terechte vraag — wat doen we met de wachtwoorden? Om onze wachtwoorden en andere gevoelige gegevens veilig op te slaan, helpt het mechanisme van omgevingsvariabelen van onze buildmachine. In de projectinstellingen van CircleCI kiezen we voor Omgevingsvariabelen.
En we voegen de volgende variabelen toe:
- key: GOOGLE_APPLICATION_CREDENTIALS
value: de inhoud van het JSON-bestand met de sleutel van het serviceaccount gcloud - key: MATCH_PASSWORD
value: wachtwoord voor het decoderen van de github-repository met certificaten - key: FASTLANE_PASSWORD
value: wachtwoord van het infrastructuuraccount van het Apple Developer Portal
We slaan de wijzigingen op, creëren een PR en sturen deze ter beoordeling naar onze teamleider.
Conclusies
Als resultaat van deze eenvoudige handelingen hebben we een goede, stabiel werkende omgeving met de mogelijkheid om video's op te nemen van de scherm van het apparaat tijdens het testen. In het testvoorbeeld heb ik het model iPhone X opgegeven, maar de boerderij biedt een ruime keuze uit verschillende modellen en versies van iOS.
Het tweede deel is gewijd aan de stap-voor-stap configuratie van Firebase Test Lab voor een Android-project.
Bron: habr.com
