Mein Name ist Dmitrij, ich arbeite als Tester bei der Firma . Kürzlich habe ich mich intensiv mit einer relativ neuen Funktion von beschäftigt — dem instrumentalen Testen von iOS-Anwendungen mit dem nativen Testframework XCUITest.
Zuvor habe ich Firebase Test Lab für Android ausprobiert und war begeistert davon, also wollte ich die Testinfrastruktur für das iOS-Projekt auf die gleiche Weise aufsetzen. Dabei musste ich viel googeln und nicht alles hat beim ersten Mal geklappt, weshalb ich beschlossen habe, einen Tutorial-Artikel für diejenigen zu schreiben, die noch vor dieser Herausforderung stehen.
Wenn Sie also UI-Tests für Ihr iOS-Projekt haben, können Sie sie noch heute auf echten Geräten ausprobieren, die freundlich von der Corporation of Good zur Verfügung gestellt werden. Interessierte sind herzlich willkommen.
In diesem Artikel habe ich mich auf einige grundlegende Daten gestützt — ein privates Repository auf GitHub und das Build-System CircleCI. Der Name der Anwendung ist AmazingApp, und der Bundle-ID lautet com.company.amazingapp. Diese Informationen gebe ich gleich zu Beginn an, um spätere Verwirrung zu vermeiden.
Wenn Sie bestimmte Entscheidungen in Ihrem Projekt anders umgesetzt haben, teilen Sie Ihre Erfahrungen in den Kommentaren.
1. Die Tests selbst
Wir erstellen einen neuen Branch für UI-Tests:
$ git checkout develop
$ git pull
$ git checkout -b "feature/add-ui-tests"
Öffnen Sie das Projekt in XCode und erstellen Sie ein neues Ziel (Target) für die UI-Tests [XCode -> Datei -> Neu -> Ziel -> iOS Testing Bundle], und geben Sie ihm einen aussagekräftigen Namen: AmazingAppUITests.
Gehen Sie zum Abschnitt Build-Phasen des erstellten Targets und überprüfen Sie, ob die Zielabhängigkeiten — AmazingApp, in Compile Sources — AmazingAppUITests.swift vorhanden sind.
Eine gute Praxis ist es, verschiedene Build-Varianten in separate Schemes zu unterteilen. Erstellen Sie ein Scheme für unsere UI-Tests [XCode -> Produkt -> Scheme -> Neues Scheme] und geben Sie ihm denselben Namen: AmazingAppUITests.
Der Build des erstellten Schemes sollte das Ziel der Hauptanwendung — AmazingApp und das Ziel der UI-Tests — AmazingAppUITests enthalten — siehe Screenshot.
Als nächstes erstellen wir eine neue Build-Konfiguration für die UI-Tests. In XCode klicken Sie auf die Projektdatei, gehen zum Abschnitt Info. Klicken Sie auf “+” und erstellen Sie eine neue Konfiguration, zum Beispiel XCtest. Dies wird uns später helfen, um Probleme mit der Code-Signierung zu vermeiden.
Ihr Projekt umfasst mindestens drei Targets: die Hauptanwendung, Unit-Tests (die haben Sie, oder?) und das von uns erstellte UI-Test-Target.
Wir öffnen das Target AmazingApp, gehen zum Tab Build Settings und dann zum Abschnitt Code Signing Identity. Für die Konfiguration von XCtest wählen wir iOS Developer. Im Abschnitt Code Signing Style wählen wir Manual. Das Provisioning-Profil haben wir noch nicht erstellt, aber dazu kommen wir später.
Für das Target AmazingAppUITests machen wir dasselbe, aber im Feld Product Bundle Identifier tragen wir com.company.amazingappuitests ein.
2. Projektkonfiguration im Apple Developer Program
Wir gehen auf die Seite des Apple Developer Program, navigieren zum Abschnitt Certificates, Identifiers & Profiles und dann zu App IDs im Punkt Identifiers. Wir erstellen eine neue App ID mit dem Namen AmazingAppUITests und bundleID com.company.amazingappuitests.
Jetzt haben wir die Möglichkeit, unsere Tests mit einem separaten Zertifikat zu signieren, aber… Der Build-Prozess für Testzwecke umfasst den Bau der Anwendung selbst und den Test-Runner. Somit stehen wir vor dem Problem, zwei Bundle IDs mit einem einzigen Provisioning-Profil zu signieren. Glücklicherweise gibt es eine einfache und elegante Lösung – die Wildcard App ID. Wir wiederholen den Prozess zur Erstellung einer neuen App ID, aber statt einer Explicit App ID wählen wir die Wildcard App ID, wie auf dem Screenshot.
An diesem Punkt ist die Arbeit mit developer.apple.com abgeschlossen, aber wir werden das Browserfenster nicht schließen. Gehen wir zu und lesen die Match-Utility von Anfang bis Ende.
Aufmerksame Leser haben bemerkt, dass wir für die Nutzung dieses Tools ein privates Repository und ein Konto benötigen, das sowohl Zugriff auf das Apple Developer Program als auch auf Github hat. Erstellen Sie (wenn noch nicht vorhanden) ein Konto wie InfrastructureAccount@your.company.domain, denken Sie sich ein starkes Passwort aus, registrieren Sie es bei developer.apple.com und weisen Sie es als Projektadministrator zu. Anschließend gewähren wir dem Konto Zugriff auf das Github-Repository Ihres Unternehmens und erstellen ein neues privates Repository mit einem Namen wie AmazingAppMatch.
3. Einrichtung von Fastlane und dem Match-Utility
Öffnen Sie das Terminal, wechseln Sie in das Projektverzeichnis und initialisieren Sie Fastlane wie im . Nach Eingabe des Befehls
$ fastlane initwerden Sie aufgefordert, die verfügbaren Nutzungskonfigurationen auszuwählen. Wählen Sie die vierte Option - manuelle Projekteinstellung.
Im Projekt gibt es ein neues Verzeichnis 'fastlane', das zwei Dateien enthält – Appfile und Fastfile. Kurz gesagt: Im Appfile speichern wir die Dienstdaten, während im Fastfile die Jobs beschrieben werden, die in der Terminologie von Fastlane 'lanes' genannt werden. Ich empfehle die offizielle Dokumentation zur Lektüre: , .
Öffnen Sie das Appfile in Ihrem bevorzugten Texteditor und bringen Sie es in folgendes Format:
app_identifier "com.company.amazingapp" # Bundle-ID
apple_dev_portal_id "infrastructureaccount@your.company.domain" # Der erstellte Infrastruktur-Account mit Bearbeitungsrechten für das iOS-Projekt im Apple Developer Program.
team_id "LSDY3IFJAY9" # Ihre Team-ID im Developer Portal
Gehen Sie zurück zum Terminal und beginnen Sie gemäß der offiziellen Anleitung mit der Einrichtung von match.
$ fastlane match init
$ fastlane match development
Geben Sie anschließend die angeforderten Daten ein – Repository, Konto, Passwort usw.
Wichtig: Bei der ersten Ausführung wird das Tool match nach dem Passwort zur Entschlüsselung des Repositories fragen. Es ist sehr wichtig, dieses Passwort zu speichern, da es uns während der Konfiguration des CI-Servers nützlich sein wird!
Im 'fastlane'-Ordner wurde eine neue Datei – Matchfile – erstellt. Öffnen Sie diese in Ihrem bevorzugten Texteditor und bringen Sie sie in folgendes Format:
git_url("https://github.com/YourCompany/AmazingAppMatch") # Erstelltes privates Repository zur Speicherung von Zertifikaten und Profilen.
type("development") # Der Standardtyp, kann sein: appstore, adhoc, enterprise oder development
app_identifier("com.company.amazingapp")
username("infrastructureaccount@your.company.domain") # Ihr Infrastrukturkonto-Benutzername im Apple Developer Portal
Füllen Sie es genau so aus, wenn wir später match zur Signierung von Builds für den Upload in Crashlytics und/oder AppStore verwenden möchten, d.h. für die Signierung der Bundle-ID Ihrer Anwendung.
Wie wir uns erinnern, haben wir jedoch für die Signierung des Test-Builds eine spezielle Wildcard-ID erstellt. Daher öffnen wir die Fastfile und fügen die neue Lane hinzu:
lane :testing_build_for_firebase do
match(
type: "development",
readonly: true,
app_identifier: "com.company.*",
git_branch: "uitests" # Erstellen eines separaten Branches für das Development-Zertifikat zur Signierung des Test-Builds.
)
end
Speichern, geben wir im Terminal ein
fastlane testing_build_for_firebaseund sehen, wie fastlane ein neues Zertifikat erstellt und es im Repository ablegt. Ausgezeichnet!
Öffnen Sie XCode. Jetzt haben wir das benötigte Provisioning-Profil vom Typ Match Development com.company.*, das wir im Abschnitt Provisioning-Profil für die Zielgruppen AmazingApp und AmazingAppUITests angeben müssen.
Es fehlt nur noch die Lane für den Testaufbau zu ergänzen. Gehen wir zu Plugin-Projekt für fastlane, das die Konfiguration des Exports an Firebase Test Lab erleichtert und die Anweisungen befolgt.
Wir übernehmen aus dem ursprünglichen Beispiel, damit unser lane testing_build_for_firebase schließlich so aussieht:
lane :testing_build_for_firebase do
match(
type: "development",
readonly: true,
app_identifier: "com.company.*",
git_branch: "uitests"
)
scan(
scheme: 'AmazingAppUITests', # UI-Test-Schema
clean: true, # Empfohlen: Dies stellt sicher, dass der Build keine unnötigen Dateien enthält
skip_detect_devices: true, # Erforderlich
build_for_testing: true, # Erforderlich
sdk: 'iphoneos', # Erforderlich
should_zip_build_products: true, # Muss wahr sein, um das richtige Format für Firebase Test Lab festzulegen
)
firebase_test_lab_ios_xctest(
gcp_project: 'AmazingAppUITests', # Ihr Google Cloud-Projektname (auf diese Zeile kommen wir später zurück)
devices: [ # Gerät(e), auf dem die Tests ausgeführt werden
{
ios_model_id: 'iphonex', # Gerätemodell-ID, siehe gcloud-Befehl oben
ios_version_id: '12.0', # iOS-Version-ID, siehe gcloud-Befehl oben
locale: 'de_DE', # Optional: standardmäßig auf de_DE, wenn nicht festgelegt
orientation: 'portrait' # Optional: standardmäßig auf Hochformat, wenn nicht festgelegt
}
]
)
end
Für vollständige Informationen zur Konfiguration von fastlane in CircleCI empfehle ich, die offizielle Dokumentation zu lesen. .
Vergessen wir nicht, unsere config.yml um eine neue Aufgabe zu ergänzen:
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 # aktualisiert Abhängigkeiten
- run:
name: gcloud-sdk installieren # auf dem Mac muss gcloud installiert werden
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: App für Tests bauen
command: fastlane testing_build_for_firebase # startet den Buildlane und sendet an Firebase
4. Und was ist mit unserer Testumgebung? Wir richten Firebase ein.
Lass uns nun zu dem übergehen, wofür dieser Artikel eigentlich geschrieben wurde.
Vielleicht nutzt Ihre Anwendung Firebase im kostenlosen Tarif, vielleicht auch nicht. Das ist jedoch unerheblich, da wir für Testzwecke ein separates Projekt mit einem Jahr kostenloser Nutzung erstellen können (cool, oder?)
Wir loggen uns in unser Infrastruktur-Konto ein (oder ein beliebiges anderes, ist egal), und gehen zu . Wir erstellen ein neues Projekt mit dem Namen AmazingAppUITests.
Wichtig: Im vorherigen Schritt sollte im Fastfile im Lane firebase_test_lab_ios_xctest der Parameter gcp_project dem Projektnamen entsprechen.
Die Standardkonfiguration ist für uns vollkommen ausreichend.
Wir schließen den Tab nicht und registrieren uns unter demselben Konto bei — dies ist eine erforderliche Maßnahme, da die Kommunikation mit Firebase über die gcloud-Konsole erfolgt.
Google schenkt 300$ für ein Jahr, was im Kontext der Durchführung von automatisierten Tests einem Jahr kostenloser Nutzung des Dienstes entspricht. Wir geben die Zahlungsdaten ein, warten auf die Testabbuchung von 1$ und erhalten 300$ auf dem Konto. Nach einem Jahr wird das Projekt automatisch auf den kostenlosen Tarif umgestellt, sodass man sich keine Sorgen über mögliche Geldverluste machen muss.
Lassen Sie uns zum Tab mit dem Firebase-Projekt zurückkehren und es auf den Blaze-Tarif umstellen — jetzt haben wir Mittel, um im Falle einer Überschreitung des Limits zu zahlen.
Im gcloud-Interface wählen wir unser Firebase-Projekt aus, gehen zu „Katalog“ im Hauptmenü und fügen die Cloud Testing API sowie die Cloud Tools Result API hinzu.
Dann wechseln wir zu „IAM und Verwaltung“ -> Dienstkonten -> Dienstkonto erstellen. Wir vergeben Bearbeitungsrechte für das Projekt.
Wir erstellen einen API-Schlüssel im JSON-Format.
Das heruntergeladene JSON werden wir später benötigen, aber vorerst betrachten wir die Konfiguration des Test Labs als abgeschlossen.
5. Konfiguration von CircleCI
Es stellt sich eine berechtigte Frage — was machen wir mit Passwörtern? Um unsere Passwörter und andere sensible Daten sicher zu speichern, nutzen wir den Mechanismus der Umgebungsvariablen in unserer Build-Maschine. In den Projekteinstellungen von CircleCI wählen wir Umgebungsvariablen aus.
Und wir legen die folgenden Variablen an:
- key: GOOGLE_APPLICATION_CREDENTIALS
value: Inhalt der JSON-Datei für die Schlüssel des Dienstkontos in gcloud - key: MATCH_PASSWORD
value: Passwort zum Entschlüsseln des GitHub-Repositories mit den Zertifikaten - key: FASTLANE_PASSWORD
value: Passwort für das Infrastrukturkonto im Apple Developer Portal
Änderungen speichern, einen PR erstellen und zur Überprüfung an den Teamleiter senden.
Ergebnisse
Durch diese einfachen Schritte haben wir eine gute, stabil funktionierende Umgebung geschaffen, die es ermöglicht, während der Testdurchführung Bildschirmaufnahmen des Geräts zu machen. Im Testbeispiel habe ich das Modell iPhone X angegeben, aber die Farm bietet eine umfangreiche Auswahl an Kombinationen verschiedener Modelle und iOS-Versionen.
Der zweite Teil wird sich mit der Schritt-für-Schritt-Einrichtung von Firebase Test Lab für ein Android-Projekt beschäftigen.
Quelle: habr.com
