In diesem Blogeintrag werde ich das Page Object Model (POM) Pattern vorstellen und zeigen wie ich das Pattern im Flutter Kontext verwende.
Wenn man mit UI Tests in Flutter anfängt, fängt man in der Regel erst mal damit an, alle Steps im Test selber auszuführen.
In unseren Beispiel testen wir eine Dart (das Spiel, nicht die Programmiersprache 😉 ) Zähler App. Der Test deckt folgendes Szenario ab:
- Der Spieler startet ein Spiel „501“.
- Der Spieler wirft eine Triple 20. Dafür klickt der Spieler zuerst auf den mal drei Button, danach auf den 20 Button.
- Der Test prüft, ob statt der 501 nun die 441 angezeigt wird (501 – 20 * 3)
Die Art wie dieser Test geschrieben ist, ist aus meiner Sicht der „intuitive Weg“ wie man so einem Test als erstes abbildet. Es werden hier direkt einige Nachteile sichtbar.
Der Test ist ziemlich unleserlich. Als Entwickler muss man Zeile für Zeile prüfen, um wirklich zu verstehen was getestet wird. Es wird schnell zu doppelten Source-Code kommen, z.B. sobald ich einen zweiten Test schreibe, der wieder den 501 Spielmodus startet.
Hier kommt das POM Pattern ins Spiel. Es wird für jede Seite in der Anwendung eine eigene Klasse implementiert. In unserem Fall also eine MenuPage und eine GamePage. Nun werden alle Actions und Steps die auf der jeweiligen Seite ausgeführt werden hier implementiert.
- Action -> Aktivitäten auf dieser Page, also z.B. selectTriple in der GamePage
- Steps -> Aktionen die zu einer anderen Page navigieren, also z.B. start501Game in der MenuPage
Jede Page sollte den Tester direkt als Konstruktor Parameter erhalten, weil dieser in diesem Kontext immer benötigt wird. Jede Step-Methode sollte das Page Objekt zurückgeben, auf das navigiert wird. In unserem Fall gibt start501Game die GamePage zurück. Das ermöglicht, dass man im Test direkt mit dem nächsten PageObject weiter arbeiten kann. Der fertige Test sieht dann wie folgt aus.
Aus meiner Sicht deutlich lesbarer (man sollte hier bedenken, dass UI Tests oft größer ausfallen als drei Aktionen) und wartbarer. Wenn sich z.B. die Bedienung des Spielstarts ändert, muss ich nicht alle Tests überprüfen, wo dieser Aufruf verwendet wurde. Ich kann einfach in die jeweilige Page-Klasse gehen und die Logik anpassen. Die Wahrscheinlichkeit doppelten Source-Code im Tests zu implementieren ist ebenfalls deutlich geringer.