Es ist ein Jahr her, seit ich dem Team beigetreten bin, das sich um die Lösung für die automatisierte Android-Testung für einen unserer respektablen Kunden kümmert. Nun ist es an der Zeit, die wertvolle Erfahrung zu teilen. Dies ist Teil 1 der Android-Testreihe im Blog:
- Android Testing (Teil 1): AWS Device Farm vs Firebase TestLab
- Android Testing (Teil 2): Kotlin DSL für Espresso und UIAutomator
- Android Testing (Teil 3): Die Kraft des Robot Pattern mit Kotlin
Unsere Aufgabe bestand darin, nur End-to-End-Tests zu automatisieren. Und eine der ersten Entscheidungen, die wir treffen mussten, war die Wahl eines seriösen Unternehmens, das einen Service zum “Mieten” aller Arten von physischen Geräten für Testzwecke anbietet. Zunächst dachten wir an eine Self-Hosting-Lösung, die mit der CI-Pipeline verdrahtet werden könnte, aber wir konnten niemals eine ausreichend granulare Gerätevielfalt bieten. Daher begannen wir, nach Cloud-Lösungen zu suchen.
Da wir eine Lösung benötigten, die sowohl Android als auch iOS-Plattformen unterstützt und eine große Anzahl verschiedener Geräte aufweist, stach AWS DeviceFarm als Lösung hervor, der wir vertrauen konnten, dass sie stabil genug ist, einen reaktionsschnellen Support bietet und allgemein einfach zu bedienen ist.
AWS DeviceFarm
Wenn Sie es zum ersten Mal verwenden, werden Sie wahrscheinlich den Service über die Web-Benutzeroberfläche ausprobieren. Es sind nur ein paar obligatorische Schritte erforderlich, um den Testlauf zu starten:
- Wählen Sie einen Testtyp: Instrumentation
- Laden Sie die Test APK hoch
- Laden Sie die App APK hoch
- Wählen Sie Geräte aus (erstellen Sie einen sogenannten Geräte-Pool)
- Wenn Sie kein zusätzliches Datapaket bereitstellen müssen, klicken Sie auf “Ausführen”.
- Und das ist im Grunde alles. Die Tests werden auf den ausgewählten Geräten ausgeführt und wenn alles gut läuft, sehen Sie die kumulative Bestehens-/Nichtbestehensstatistik pro Gerät sowie eine detaillierte Liste der bestandenen und nicht bestandenen Tests.
Für jeden Test erhalten Sie standardmäßig das Instrumentierungsprotokoll, Logcat und die Videoaufnahme.
Die Web-Benutzeroberfläche ist jedoch nicht sehr nützlich, wenn die CI-Pipeline verwendet wird. Daher müssen wir entweder die AWS CLI oder ein Plugin für den Build-Server verwenden. Wir haben Jenkins verwendet, das die Kommunikation mit AWS DeviceFarm unterstützt (über das Plugin natürlich).
Es hat sehr gut funktioniert, zumindest was die Ausführung der Tests betrifft. Ein erstes großes Problem, auf das wir gestoßen sind, war das Fehlen von Berichten. Es gibt keine Option zum Hinzufügen einer E-Mail-Adresse oder E-Mail-Adressen, die den Testbericht erhalten sollen. Tatsächlich gibt es überhaupt keinen Bericht, nicht einmal einen zusammengefassten Bericht, der an den Kunden weitergeleitet werden könnte. Uns blieb nur die Möglichkeit, den Zugriff auf unser AWS-Projekt zu ermöglichen, damit die Testergebnisse über die Web-UI überprüft werden konnten.
JUnit4-Unterstützung – Deal Breaker
Auf der Android-Seite war das Testverfahren bereits kompliziert genug und wir mussten einige Kompromisse eingehen. Einer davon bestand darin, eine strenge Reihenfolge der Testausführung aufgrund des komplexen und langwierigen Anmeldeverfahrens in der App zu erzwingen.
Um dies zu tun, haben wir als ersten Schritt präzise Testsuiten erstellt. Ein praktisches Verhalten der Testsuitendefinition auf Android besteht darin, dass Testklassen in der Reihenfolge ausgeführt werden, wie sie in der @SuiteClasses-Annotation definiert sind.
Als zweiten Teil mussten wir die Tests innerhalb der Testklassen ebenfalls ordnen, was wir mit der einzigen verfügbaren Option getan haben: der @FixMethodOrder-Annotation.
Und das war das Ende der Reise für uns mit AWS DeviceFarm, denn sie implementieren JUnit4 nur teilweise, ohne Unterstützung für die Definition von Testsuiten oder für FixMethodOrder! Da uns die Optionen ausgegangen waren, mussten wir den Service aufgeben, da wir die Tests nicht so ausführen konnten, wie wir wollten.
Firebase TestLab
Bevor wir AWS aufgegeben haben, mussten wir sicherstellen, dass wir einen Service finden können, der immer noch seriös genug ist, eine gute Unterstützung bietet und keine solchen JUnit4-Beschränkungen hat. Wir haben Firebase ausprobiert und es hat funktioniert.
Der Einrichtungsvorgang über die Web-Benutzeroberfläche ist fast identisch mit AWS:
- Wählen Sie einen Testtyp (auch Instrumentierung)
- Laden Sie beide APKs hoch
- Wählen Sie ein Gerät aus
- Führen Sie es aus.
- Beobachten Sie die Testergebnisse pro Gerät und pro Test mit Zugriff auf Videoaufzeichnungen und Protokolle.
- Natürlich können wir die Web-Benutzeroberfläche nicht verwenden, also verwenden wir die CLI-Lösung für Firebase:
gcloud.
Mit gcloud können wir den Testtyp, die Pfade zu den APK-Dateien, das Ergebnisverzeichnis und den Bucket für Google Cloud Storage sowie das Testziel definieren, das neben allen Standardoptionen wie Testpaket oder individuellem Test auch die Testsuite als Ziel akzeptiert und die Ausführungsreihenfolge berücksichtigt.
Obwohl es ähnlich wie AWS DeviceFarm funktioniert, basiert Firebase TestLab auf dem Google-Stack und speichert daher alle Testergebnisse im Bucket auf Google Cloud Storage, was großartig ist, da wir direkt auf die Dateien zugreifen können.
Kleine Anmerkung hier: Um den benutzerdefinierten Bucket und Pfad pro Testausführung festzulegen, ist ein kostenpflichtiger Zugriff auf Google Cloud Storage erforderlich. Im Fall der kostenlosen Speichernutzung werden die Testergebnisse im Verzeichnis
testlab/random-hashgespeichert und nach 90 Tagen entfernt. Da wir direkt auf die Testergebnisse zugreifen konnten, konnten wir den Testbericht erstellen, wie wir es wollten, was unserem Kunden sehr gefallen hat. Ich möchte jedoch darauf hinweisen, dass Firebase keine systematische Berichtslösung bietet, bei der nur die Mailingliste erstellt wird, um die Ergebnisse zu erhalten. Es gibt eine zusammengefasste Ergebnisanzeige pro Gerät in der Konsolenausgabe.
Timeouts
Obwohl Firebase uns die Möglichkeit bietet, Testsuiten auszuführen, kam dies nicht kostenlos. Eine maximale Ausführungszeit für Tests beträgt 30 Minuten. Dies reicht für 90% der Anwendungsfälle aus, aber in unserem Fall erwies sich eine Testsuite, die alle Testklassen enthält, als problematische Lösung, da unsere End-to-End-Tests 60+ Minuten dauern.
Der Grund für diese 30-minütige Begrenzung, laut Diskussionen in Google-Foren und Slack, ist die Systemstabilität, so haben sie sich auf 30 Minuten geeinigt. Die Ausführung von Tests, die länger als das dauern würden, würde ohne Ergebnisse unterbrochen.
Wir haben dieses Problem gelöst, indem wir viele kleine Testsuiten erstellt haben, die nacheinander ausgeführt werden, mit separaten gcloud-Aufrufen. Als Folge davon war die Berichtserstellung noch komplexer, aber zumindest möglich und gab uns letztendlich die funktionierende Lösung.
Vergleich
Hier werden wir versuchen, die Vor- und Nachteile beider Dienste zusammenzufassen:
- CLI-Einfachheit: Firebase
- Plugin-Zugänglichkeit: AWS
- Systemberichte (Mailingliste): Keine
- Berichtszugänglichkeit: Firebase
- Zusammengefasster Bericht: Firebase
- Geräteauswahl: AWS (Firebase bietet 15-20 verschiedene Geräte)
- Aktuelle Kompatibilität: Firebase
- Support-Zugänglichkeit: Firebase (fast sofort über Slack)
- Fernsteuerung des Geräts: AWS
- Systemstabilität: AWS (Bei Firebase gab es viele “Infrastrukturausfälle” auf bestimmten Geräten)
- IDE-Integration: Firebase
- iOS-Unterstützung: Beide (mit einem leichten Vorteil für AWS, da die Unterstützung für Firebase XCUITest zum Zeitpunkt des Schreibens in der geschlossenen Beta ist)
Diese Liste könnte endlos fortgesetzt werden, aber ihr Ziel ist es nicht, Ihnen zu sagen: “Sie sollten niemals Service X verwenden”. Ich wollte auf die Probleme und Vorteile anhand eines realen Beispiels hinweisen.
Fazit
Generell habe ich als Benutzer dieser Dienste das Gefühl, dass es keine große Wahlfreiheit gibt. Je höher unsere Anforderungen und Erwartungen sind, desto höher sind auch die Barrieren, auf die wir stoßen, und das passiert viel öfter. Das Schlimmste daran ist, dass man sich dieser winzigen Probleme bei der Entscheidungsfindung nicht bewusst sein kann. Wer hätte schon an JUnit4-Probleme bei AWS gedacht… aber es passiert.
Hinweis: Diese Dienste werden in unbegrenzten kostenpflichtigen Plänen verwendet, einschließlich des durch die Nutzung von Google Cloud Storage generierten Datenverkehrs. Es gab keine Einschränkungen des Dienstes aufgrund von kostenloser oder Testnutzung.
Seien Sie vorsichtig!
