Oh verdammt! Testen Sie das Bild mit Jetpack Compose von Anders Ullnæss | Januar 2022

# beachbod2022

Screenshot-Tests (oder Screenshot-Tests, ich werde beide Begriffe abwechselnd verwenden) ist eine Art von Tests, die uns hilft sicherzustellen, dass sich unsere Benutzeroberfläche nicht unbeabsichtigt ändert.

Der Testschuss besteht aus 2 Schritten:

  1. Aufzeichnen
  2. Bestätigen Sie

Aufzeichnen

Wenn wir mit der Erstellung eines Teils der Benutzeroberfläche fertig sind, egal ob es sich um einen Vollbildmodus oder nur um eine Schaltfläche handelt, schreiben wir eine Testaufnahme und nehmen auf. Der Screenshot wird in unserem Quellcode gespeichert und definiert die Baseline für unsere Benutzeroberfläche.

Bestätigen Sie

Wir werden höchstwahrscheinlich später auf einen Code eingehen, der die Benutzeroberfläche von unserem ursprünglichen Screenshot ändern kann oder auch nicht.
Bei der Überprüfung nimmt die Testaufnahme einen neuen Screenshot auf und vergleicht die beiden Bilder. Wenn sie nicht identisch sind, schlägt unsere Testaufnahme fehl.

“Aber was, wenn ich daran denke, die Benutzeroberfläche zu ändern?” Ruiniert das nicht meine Testaufnahme?“
Ja er wird. Wenn wir die Benutzeroberfläche absichtlich ändern, erfassen wir nur erneut.
Als netter Bonus zeigt unsere Auszahlungsanfrage den Look vorher und nachher, was unsere bewerteten Freunde glücklich macht!

Wer hätte gedacht, dass Designer ihre Meinung ändern könnten?

Meiner Erfahrung nach ist das Testen von Videos bei iOS-Entwicklern sehr beliebt, und es wird selten von Android-Entwicklern gesprochen. Ich habe noch nie an Projekten gearbeitet, bei denen dies zuvor für Android durchgeführt wurde. Einer der Gründe könnte sein, dass das iOS-Tool fantastisch und einfach zu starten ist. (Meine Kollegen verwenden https://github.com/pointfreeco/swift-snapshot-testing). Nicht so sehr für Android, obwohl ich denke, dass sich die Dinge verbessern.

In jedem Fall haben wir uns von iOS-Kollegen inspirieren lassen und wollten es selbst ausprobieren. Wir haben auch mit der Arbeit an Jetpack Compose begonnen und dachten, es wäre schön, alle unsere neuen Compose-UI-Komponenten zu testen.

Der erste Schritt war, die richtige Bibliothek zu finden. Von den wenigen Bibliotheken fanden wir nur eine, die Compose erwähnte, also war es eine einfache Wahl:
https://github.com/pedrovgs/Shot

Für Grundlagen zum Schreiben eines Screenshot-Tests für Jetpack Compose lesen Sie hier den Blogbeitrag der Bibliothek:
https://blog.karumi.com/jetpack-compose-screenshot-testing-with-shot/

Da dieser Blogbeitrag bereits die Grundlagen behandelt, werde ich mich auf die zusätzlichen Schritte konzentrieren, die wir unternommen haben:

  1. Durchführung von Aufnahmetests im Rahmen von CI/CD
  2. Arbeiten Sie mit Screenshots, die auf verschiedenen Emulatorarchitekturen aufgenommen wurden
  3. Machen Sie Tests schnell und einfach zu schreiben

In unserem Projekt verwenden wir Bitrise für CI / CD, aber unser Ansatz sollte auch für andere Einstellungen funktionieren. Mit Shot führen Sie Screenshot-Tests durch die Gradle-Aufgabe durch ./gradlew internalDebugExecuteScreenshotTests wo internalDebug ist Ihre Variante der Herstellung.

Wenn Sie wie wir bereits einige UI-Tests haben, die keine Screenshots sind, müssen Sie etwas Spezifischeres einstellen. Wir tun dies, indem wir eine Namenskonvention verwenden und alle unsere Screenshot-Tests benennen *ScreenshotTest und führen Sie den Build-Befehl wie folgt aus:

./gradlew internalDebugExecuteScreenshots -Pandroid.testIntrumentationRunnerArguments.tests_regex=.*ScreenshotTest.*

Wenn Sie ihn lokal ausführen, wird dieser Befehl auf jedem Emulator oder Gerät ausgeführt, das Sie verwenden. Wenn Sie als Teil Ihres CI/CD arbeiten, müssen Sie zuerst einen Emulator erstellen und ausführen. In Bitrise haben Sie dafür einen netten AVD-Manager-Schritt:

Beim lokalen Erstellen von Screenshots ist es wichtig, denselben Emulatortyp zu verwenden, daher haben wir auch ein Skript zum Erstellen unseres Emulators mit dem entsprechenden Namen bissig. (Dies kann auch in anderen CIs / CDs ohne den AVD-Manager-Schritt verwendet werden):

Dieses Skript ist im Laufe der Zeit etwas gewachsen, um meinen Kollegen dabei zu unterstützen, einen neuen Mac mit Apple-Silikon zu bekommen (dazu später mehr), aber ein wichtiger Teil passiert in der letzten Zeile. Erstellt einen Emulator mit den gleichen Spezifikationen wie der von Bitrise.

Nach dem Schritt AVD Manager in Bitrise müssen Sie warten, bis der Emulator bereit ist, bevor Sie die Screenshot-Tests ausführen. Ich habe eine Weile gebraucht, um herauszufinden, warum es nicht funktioniert hat, da die Fehlermeldung, die Sie erhalten, nicht sehr klar ist.
Dazu gibt es natürlich einen Schritt:

Geduld ist eine Tugend

Wir führen dieses Skript lokal aus, um die Screenshots auszuführen (zu überprüfen):

Das Skript zum Erfassen von Screenshots ist sehr ähnlich, jedoch mit dem Capture-Parameter:

Beide verwenden dieses Skript, um den Emulator auszuführen:

Ich habe die Abbruchleitung des Emulators eingeschaltet, als die Tests vorbei waren. Ohne sie würden Sie einen neuen Emulator erhalten, der jedes Mal ausgeführt würde, wenn Sie das Skript ausführen (und Tests würden auf allen gleichzeitig ausgeführt).

Wir zahlen derzeit nicht für die schnellsten Maschinen in Bitrise, daher ist die Pipeline leider zu langsam (25-30 Minuten), um für jede Auszahlungsanforderung ausgeführt zu werden. Das Ausführen der Aufnahmen selbst ist nicht so schlimm, aber das Erstellen und Ausführen des Emulators ist ziemlich langsam. Wenn Sie den Emulator zuvor erstellt und ausgeführt haben, dauert es beim lokalen Start nur 1-2 Minuten, um unsere ~ 50 Tests auszuführen, und diese Zahl erhöht sich nicht wesentlich, wenn neue Tests hinzugefügt werden.

Anstelle jeder Auszahlungsanforderung führen wir die Pipeline jede Nacht aus und senden sie an den Teams-Kanal, wenn sie fehlschlägt. Nicht ideal, aber gut genug:

Vielleicht sollte ich unsere Testaufnahmen reparieren, anstatt Blogbeiträge zu schreiben?

Beim Vergleich von Screenshots, die auf Emulatoren mit unterschiedlichen Architekturen aufgenommen wurden, kann es Unterschiede geben, die für das menschliche Auge nicht sichtbar sind, aber unser Testbild wird trotzdem fehlschlagen. Auf dem neuen Apple-Silikon-Mac meines Kollegen kann kein x86_64-Emulator wie auf meinem älteren Mac oder dem Ubuntu-Docker-Image von Bitrice ausgeführt werden.

Unsere suboptimale Lösung dafür besteht darin, unseren Aufnahmetests etwas Toleranz hinzuzufügen. Wir lassen die Tests erfolgreich sein, wenn der Unterschied zwischen den beiden Screenshots weniger als 2 % beträgt.

Dies kann zu kleinen unbeabsichtigten Änderungen an der Benutzeroberfläche führen, die von Tests nicht erkannt werden. Dies kann ein echtes Problem sein und wir hatten bereits einige Fälle, in denen Screenshot-Tests keine Änderung in der Benutzeroberfläche festgestellt haben:

  1. Ändern Sie ein Symbol in den Vollbildmodus
  2. Es verändert die Marge ein wenig

Das Schreiben von Filmmaterialtests kann mühsam und repetitiv sein, daher möchten wir, dass sie einfach zu schreiben sind und sich nicht wie eine Verpflichtung anfühlen.

Mit Jetpack Compose erstellen wir regelmäßig Reviews unserer Komponenten, die unterschiedliche Konfigurationen zeigen.

Wenn wir Footage-Tests erstellen, wollen wir das Gleiche.
Also haben wir angefangen, Testaufnahmen unserer Bewertungen zu erstellen:

Mit der Philosophie, für jede Rezension einen Screenshot-Test zu machen, können wir sehen, dass alle Screenshots sehr ähnlich aussehen werden.

Fürs Erste haben wir eine Live-Vorlage in Android Studio erstellt, um sie schneller zu schreiben.

Schreiben Sie einfach einen Snap, drücken Sie auf die Registerkarte und geben Sie den Namen Ihrer Bewertung ein. Dies ist schneller, als sie jedes Mal von Hand zu schreiben, aber eine zusätzliche Verbesserung könnte darin bestehen, ein Skript zu erstellen, das einen Test für jede Überprüfungsnotiz generiert.

Das Testen der Aufzeichnung ist für Android immer noch etwas umfangreicher als für iOS, und die von uns verwendete Bibliothek hat keine großartige Integration mit Android Studio. Sie können einen Screenshot-Test nicht einfach mit der Wiedergabetaste ausführen / aufzeichnen, Sie müssen die Gradle-Aufgabe verwenden.

Der HTML-Bildverifizierungsbericht zeigt Ihnen, wenn Änderungen an Ihrer Benutzeroberfläche vorgenommen werden

Aber für mich machen diese Vorteile es immer noch wertvoll:

  1. Wir können sicher sein, dass sich unsere Benutzeroberfläche nicht unbeabsichtigt ändert
  2. Unsere Auszahlungsanträge erhalten nette Bewertungen der neuen UI, die wir vorgenommen haben, und der UI-Änderungen, die wir “kostenlos” vorgenommen haben.
  3. Wir können aufhören, die Art von Espresso-Tests zu schreiben, die prüfen, ob alle Elemente der Benutzeroberfläche auf dem Bildschirm angezeigt werden
Ich werde das nicht vermissen

Hinterlasse einen Kommentar oder kontaktiere mich, wenn du einen Snapchat haben möchtest. Wenn Sie Fragen oder Verbesserungsvorschläge zu unserem eigenen Setup haben oder Hilfe beim Einrichten für Ihr eigenes Projekt benötigen. Hier oder auf Twitter: https://twitter.com/andersullnass.

Danke an Alex von der niederländischen Android-Slack-Benutzergruppe (https://twitter.com/alex_caskey) für die großartige Hilfe, als ich dies ursprünglich gepostet habe, und vielen Dank an meinen Kollegen Cristan, der mit mir daran gearbeitet hat, die Art und Weise, wie wir die Aufnahmen testen, zu verbessern, und für die Überprüfung dieses Blog-Beitrags.