- Der einfachste Weg, UI-Tests für mobile Apps zu automatisieren
- Verfügt über eine integrierte Fehlertoleranz gegenüber der Instabilität von UI-Elementen
- UI-Elemente befinden sich nicht immer an der erwarteten Position, daher funktioniert das Tippen auf den Bildschirm nicht immer wie vorgesehen
- Versucht, die Instabilität mobiler Anwendungen und Geräte zu berücksichtigen und darauf zu reagieren
- Verfügt über eine integrierte Fehlertoleranz gegenüber Verzögerungen
- Es ist nicht nötig,
sleep()-Aufrufe in Tests einzubauen
- Weiß, dass das Laden von Inhalten (z. B. über das Netzwerk) Zeit brauchen kann, wartet automatisch, aber nicht länger als nötig
- Ermöglicht sehr schnelle Iterationen
- Tests werden interpretiert und müssen daher nicht kompiliert werden
- Kann Testdateien kontinuierlich überwachen und bei Änderungen erneut ausführen
- Bietet eine deklarative und zugleich leistungsfähige Syntax
- Tests werden in
yaml-Dateien definiert
- Einfache Einrichtung
- Eine einzelne Binärdatei, die überall funktioniert
Meinung von GN⁺
- Maestro ist ein neues Tool zur Automatisierung von Tests für mobile Apps und will die Grenzen bestehender Lösungen wie Appium, Espresso, UIAutomator und XCTest überwinden. Besonders durch die integrierte Fehlertoleranz gegenüber instabilen UI-Elementen und Verzögerungen könnte es Probleme reduzieren, die bei bisherigen Tools häufig auftreten.
- Da eine deklarative, YAML-basierte Syntax verwendet wird, könnten auch QA-Ingenieure ohne Entwicklerhintergrund Testfälle leicht schreiben. Wer mit YAML nicht vertraut ist, muss allerdings mit einem gewissen Lernaufwand rechnen.
- Unter den Tools zur Testautomatisierung mobiler Apps ist Appium weit verbreitet. Appium unterstützt verschiedene mobile Plattformen und Programmiersprachen, hat aber den Nachteil, dass Stabilitätsprobleme zu einer hohen Fehlerrate bei Tests führen können. Es bleibt abzuwarten, inwieweit Maestro diese Appium-Probleme lösen kann.
- Derzeit ist Maestro gut dokumentiert und betreibt zudem eine Slack-Community, sodass sich eine Einführung durchaus erwägen lässt. Da es sich jedoch noch um eine frühe Version handelt, scheint vor dem Einsatz in einer Produktionsumgebung eine gründliche Validierung erforderlich.
4 Kommentare
Ich habe es ausprobiert, und es ließ sich ziemlich schnell umsetzen (von der Einrichtung bis zum Erstellen der ersten Test-YAML in etwa innerhalb einer Stunde), also ganz ordentlich.
Maestro ist simpel und hat viele gute Seiten. Allerdings gibt es auf Android noch Probleme bei der Eingabe von Koreanisch. https://github.com/mobile-dev-inc/maestro/issues/146
Ein weiterer Nachteil ist, dass es im Vergleich zu anderen Test-Tools nicht besonders schnell läuft. Normalerweise werden Test-Tools im Gegensatz zu echten Nutzern sehr schnell ausgeführt, sodass Tests flaky fehlschlagen können, wenn
waitnicht präzise genug konzipiert ist. Bei Maestro ist es aber so langsam, dass man fast den Eindruck bekommt, als hätte man sich dafür entschieden, das Problem einfach durch langsames Warten zu lösen. ^^;;;Einerseits wird beim Web-Frontend-Testing ein Ansatz, der Accessibility-Elemente nutzt, immer beliebter, und das gilt auch für Mobile. (siehe https://blog.banksalad.com/tech/test-in-banksalad-ios-2/)
Bei Maestro liegt der Fokus vor allem auf Text und ID. Dadurch war es schwierig, die Rollen wie Link, Button oder Heading bei „Produktliste“ zu unterscheiden. Schade ist auch, dass sich Dinge, die im Web mit
aria-checked,aria-expandedusw. geprüft werden können, hier nicht so gut verifizieren lassen.Ich fand es umständlich, dass man bei
test-idzur Vermeidung von ID-Kollisionen Präfixe usw. anhängt und am Ende trotzdem noch einmal testen muss, ob das so gefundene Element den erwarteten Text rendert.Vielen Dank für den aufschlussreichen Kommentar.