Autorinnen: Nina Mürschberger und Iris Kellermann
Flutter von Google und React Native von Facebook sind zwei trendige Tools, mit denen Apps für mehrere Plattformen programmiert werden können. Das ist für die Developer super, für die Tester ein Gräuel. Denn wie lassen sich solche plattformunabhängigen Apps auf unterschiedlichen Plattformen und in verschiedenen Versionen ökonomisch testen, ohne dass sich Aufwand, Zeit und Kosten mit jeder weiteren Testumgebung explosionsartig vervielfachen? Die Antwort ist Testautomatisierung! Dieser Artikel zeigt, wie sich Flutter-Apps ohne Programmieraufwand testen und die Tests effizient in den Entwicklungsprozess einbinden lassen. Cross-Plattformentwicklung stellt Tester vor eine besondere Herausforderung. Entsteht mit jeder neuen Plattform neuer Testaufwand? Was ist mit den vielen Endgeräten, die sich beispielsweise in Sensoren oder Displaygröße unterscheiden? Wie kann die Applikation auf diesen sehr unterschiedlichen Endgeräten und verschiedenen Versionen der Plattformen getestet werden? Smartphones wachsen zu immer komplexeren Systemen heran, auf denen Cross-Plattform-Apps fehlerfrei laufen müssen. Zwar sind derzeit nur zwei Plattformen, nämlich Android und iOS, gängig, doch sie stehen in einer Vielzahl von Versionen zur Verfügung. Bei iOS verwenden 90 % der Nutzer das neueste iOS 14. Bei Android hingegen müssen die letzten acht Versionen unterstützt werden, um prozentual gleich viele Nutzer abzuholen. Eine weitere Herausforderung für die Testerinnen und Tester sind die kürzeren Release-Zyklen und die wachsende App-Komplexität. Tests müssen häufiger und effizienter durchgeführt werden. Updates von Apps werden durchschnittlich einmal im Monat released. Bei jedem Release werden sowohl die neuen als auch die alten Features getestet. So lassen sich Regressionen erkennen. Testautomatisierung kann die Herausforderungen von Gerätefragmentierung, unterschiedlichen Plattformversionen und kürzeren Release-Zyklen mittels Behavior Driven Development (BDD) lösen. Wir zeigen wie und beantworten dabei zwei Leitfragen: Warum fiel die Wahl hier auf BDD? Wie lässt sich eine Flutter-App damit automatisiert testen?
Flutter
Das Open Source UI-Entwicklungstoolkit Flutter von Google bedient mit einer Code-Basis sechs Plattformen: Android, iOS, Windows, Linux, macOS und Web. Ohne größere Anpassungen ist ein Flutter-Programm auf diesen Zielplattformen lauffähig. Dazu verwendet Flutter die Programmiersprache Dart. Werkzeuge für die Testautomatisierer sind wünschenswerterweise Open Source, unterstützen native Objekterkennung und ermöglichen eine plattformübergreifende Automatisierung. Flutter bietet genau das. Mit nativer Objekterkennung können robuste Tests formuliert werden. Widgets werden nicht über ihren Text-String, sondern über einen definierten eindeutigen Schlüssel „Key” identifiziert. Dies verhindert zukünftige Crashs im Test aufgrund von String-Änderungen im Laufe der Entwicklung. Eine plattformübergreifende Automatisierung reduziert den Testaufwand stark, denn so kann der einmal implementierte Test sowohl auf iOS als auch Android ausgeführt werden. Bleibt die Frage nach dem Testverfahren.
Warum BDD?
Im Idealfall soll automatisiert getestet und gleichzeitig jeder Stakeholder mit einbezogen werden. Denn alle sollten über den aktuellen Fortschritt informiert sein, unabhängig von Wissen und Erfahrung in der Softwareentwicklung. BDD ist eine spezielle Form des Test Driven Development. Die Anforderungen an das System werden in einem vorgegebenen Schema in natürlicher Sprache (in der Gherkin Syntax) geschrieben. Die so formulierten Anforderungen lassen sich anschließend direkt als Testfälle für den Quellcode verwenden. Vorteil dieser Vorgehensweise: Alle Stakeholder sind unabhängig von ihrem technischen Code-Verständnis an der Erstellung und Umsetzung der Tests beteiligt und die Anforderungen werden sofort testbar formuliert. Ein weiterer Vorteil: Die erstellten Testfälle lassen sich nicht nur manuell ausführen; sie laufen mit den geeigneten Tools auch automatisiert ab. Da die Tests in natürlicher Sprache formuliert werden, sind auch Mischformen möglich, bei denen ein Teil der Tests automatisiert und der andere manuell durchgeführt wird.
Aufbau BDD
Für BDD müssen die Anforderungen in einem speziellen Schema formuliert werden. Die bekannteste Beschreibungssprache dafür ist Gherkin. Jede Funktionalität, die das spätere System erfüllen soll, wird in Szenarien gegliedert, die verschiedene Aspekte der Funktionalität repräsentieren. Jedes Szenario besteht aus den drei Hauptschritten Given, When und Then, ergänzt ggf. durch And. Given beschreibt die Vorbedingungen des Szenarios. When beinhaltet die durchgeführten Aktionen und Then gibt die Nachbedingungen an, die im Test überprüft werden. Mit And wird das vorherige Schlüsselwort wiederholt angewandt. Wie kann dies nun in einer Flutter-Applikation aussehen?
Im Beispiel verwenden wir als Flutter- Applikation einen Terminplaner. Mit ihm sollen Termine angelegt, bearbeitet und wieder gelöscht werden (Abb. 1). Es soll die Löschen-Funktionalität getestet werden. Zuerst wird der Vorgang analysiert. Der Ablauf des Löschvorgangs wird bestehend aus Given-, And-,When- und Then-Befehlen mit dem oben erläuterten Schema in Klartext formuliert (Abb. 2). Die Löschen-Funktionalität kann getestet werden, wenn der initiale Zustand gegeben ist. Das heißt, die App hat die Startseite anzeigt, es wurde zur Terminseite navigiert und ein Projekt ist anlegt (Given). Die Aktion beginnt (When): Wenn der Termin nach links geswiped, der Löschen-Button angezeigt, gedrückt und der Vorgang anschließend im Popup mit „Yes” bestätigt wird, dann sollte der Termin gelöscht sein. Der Test ist erfolgreich durchlaufen, wenn der Termin anschließend nicht mehr in der Terminliste zu sehen ist (Then). Was steckt hinter den Klartext-Formulierungen?
Übersetzung der Testformulierung
Hinter jedem Step, also Given, And, When oder Then, steckt eine Step-Definition, bestehend aus einer Regular Expression und einer Return-Funktion (Abb. 3). Die Regular Expression gibt an, bei welchen Steps die Step-Definition ausgeführt wird. In der Return- Funktion ist implementiert, was zu tun ist – wie in diesem Beispiel der Aufruf eines Click-Handlers auf den Button mit dem Key „start_btn“. Die Step-Definitionen sind in Dart programmiert. Diese kann man sich, zumindest für die meisten Anwendungsfälle, sparen, wenn man die bereits vorgefertigten Steps des Flutter-Gherkin Paketes verwendet.
Praktische Umsetzung
Bei Testautomatisierung können die Tests beliebig oft, auf beliebig vielen Smartphone-Modellen und für beliebig viele Plattformversionen automatisiert ausgeführt werden. Wo beim manuellen Testen für jedes Smartphone- Modell ein eigener manueller Test herangezogen werden musste, ist jetzt nur ein automatisierter Test nötig. Dieser kann sowohl auf echten Endgeräten als auch in Emulatoren, wie dem Android-Emulator, oder in Simulatoren, wie dem iOS-Simulator, ausgeführt werden.
Testen im agilen Projektmanagment
Um die Tests in den agilen Entwicklungsprozess zu integrieren, bietet es sich an, die automatisierten Tests in die Continuous Integration Pipeline einzubinden (Abb. 4). Bei Änderungen des Codes, den Commits, wird dann überprüft, ob die Tests erfolgreich durchlaufen. Der Entwickler erhält so schon beim Code-Upload ein direktes Feedback, ob seine Änderungen die Kundenanforderungen erfüllen oder verletzen. Schlagen bereits erfolgreich abgeschlossene Tests fehl, kann der Entwickler sofort reagieren und die Fehler beheben.
Zusammenfassung
Die Herausforderung, eine Applikation für viele Plattformen zu entwickeln und diese auf mehreren Plattformversionen und Endgeräten mühsam zu testen, wird durch die Entwicklung plattformunabhängiger Apps elegant vereinfacht. Statt für jede Plattform ein spezifisches Software-Projekt zu implementieren, lässt sich der Aufwand auf ein einziges plattformunabhängiges Projekt mit gemeinsamer Code-Basis reduzieren. Das allein verringert den Testaufwand. Die automatisierten Tests können dann die Funktionalität für die unterschiedlichen Hardware-Voraussetzungen oder Plattformversionen auf beliebig vielen Endgeräten, Emulatoren oder Simulatoren abtesten. Mit der Einbindung in die Continuous Integration Pipeline werden die Tests ein Teil des agilen Software-Entwicklungsprozesses. Das Testen nach BDD hat zahlreiche Vorteile: Die Testfälle sind in lesbarem Klartext formuliert; fachfremde Stakeholder können Testfälle schreiben und erhalten eine klare Formulierung der Anforderungen an die App. Mit den vordefinierten Steps des Flutter- Gherkin Paketes sind die Tests schnell und mit wenig bis keinem Programmieraufwand formuliert. Eines ist sicher: Flutter ist zukunftsträchtig und es lohnt sich BDD für die Testautomatisierung auszuprobieren.
BDD in Flutter
Voraussetzung für die praktische Umsetzung:
Flutter Version 1
- Flutter-Test Package: https://pub.dev/packages/test
- Flutter-Driver Package (ermöglicht als Brücke den automatisierten Zugriff vom Test auf die App)
- https://api.flutter.dev/flutter/flutter_driver/flutter_driver-library.html
- Flutter-Gherkin Package (mit Gherkin-Parser und einem Test-Runner) https://pub.dev/packages/flutter_gherkin
Ab Flutter Version
- Integration-Test Package https://pub.dev/packages/integration_test
- Flutter-Gherkin Package State-of-the-Art
Bitte melden Sie sich an oder erstellen Sie ein Konto, um diesen Inhalt weiter zu lesen.
