Die Grundlagen der mobilen Testautomatisierung verstehen

Vorwort

Wenn es um Testautomatisierung im Allgemeinen geht, ist es leicht zu sagen, dass sie komplex ist. Wenn wir bei der klassischen Aufteilung der Testpyramide bleiben würden, kämen wir zu:

• Unit-Tests, die sowohl für Backend als auch Frontend implementiert werden können.
• Integrationstests, die heute alles bedeuten können, von API-Tests, Microservices und Drittanbieter-Service-Integration, Benutzerauthentifizierung und -autorisierung bis hin zu Quasi-Performance-Tests.
• End-to-End-Tests, die für die überwiegende Mehrheit der Test Automation Engineers und Softwareentwickler Web-Anwendungstests bedeuten würden (um einige wichtige Frameworks zu nennen: Playwright, Cypress, Selenium).

Es gibt auch Tools wie Pact für Contract Testing, Storybook für fortgeschrittenes visuelles und/oder Snapshot-Testing kombiniert mit interaktiver Dokumentation, und wahrscheinlich viele weitere, von denen ich nicht einmal weiß.

Diese Tools sind jedoch gut dokumentiert und haben große Communities um sich herum – und um ehrlich zu sein: Ich glaube nicht, dass diese Tests schwierig sind (außer vielleicht die Contract Tests).

Als ich mit der mobilen Testautomatisierung anfing, merkte ich schnell, dass das nicht der Fall war. Je tiefer ich in die mobile Softwareentwicklung einstieg, desto verwirrender wurde es. Die schiere Menge an Abhängigkeiten und Anforderungen, nur um die Anwendung zum Laufen zu bringen, war wirklich bizarr – geschweige denn das Automatisieren von Tests darauf. Die Dokumentation zu den verschiedenen Technologien war manchmal nicht sehr hilfreich, und es gab keine Artikel über das volle Spektrum möglicher mobiler Umgebungen.

Also lasst uns das ändern und über mobile Testautomatisierung sprechen, oder?

Überblick über Entwicklungs-Frameworks

Bevor wir weitermachen, müssen wir berücksichtigen, welche Technologien für die Erstellung der Anwendungen verwendet werden, die mit den mobilen Test-Frameworks getestet werden. Die populären Frameworks für die mobile Entwicklung sind:

Name

Maintainer

Technologie

Unterstützte Plattformen

Produktseite

Flutter

Google

Dart

Android / iOS / Web / Windows / macOS

https://flutter.dev/

React Native

Meta

JavaScript

Android / iOS / Web

https://reactnative.dev/

Ionic

Ionic

JavaScript

Android / iOS / Web / Windows / macOS

https://ionic.io/

NativeScript

OpenJS Foundation

JavaScript

Android / iOS / Web

https://nativescript.org/

.NET MAUI

Microsoft

C#

Android / iOS / Windows / macOS

https://dotnet.microsoft.com/en-us/apps/maui

Cordova

Apache Software Foundation

JavaScript

Android / iOS / Web / Windows / macOS

https://cordova.apache.org/

Xcode

Apple

Swift

iOS

https://developer.apple.com/xcode/

Android Studio

Google

Kotlin

Android

https://developer.android.com/studio

Laut der Stack-Overflow-Umfrage 2024 ist Flutter das beliebteste Framework für die plattformübergreifende Entwicklung. Es folgen React Native, Electron (nicht in unserer Tabelle aufgeführt, da es nur Desktop-App-Entwicklung unterstützt), .NET MAUI (und sein älterer Bruder Xamarin, der durch MAUI ersetzt wurde), Ionic und Cordova, das die Liste abschließt. Interessanterweise wird NativeScript überhaupt nicht erwähnt.

Überblick über mobile Testautomatisierungs-Frameworks

Im Folgenden findet sich ein allgemeiner Überblick über die Testautomatisierungs-Frameworks. Es gibt einige andere Frameworks, die ich absichtlich weggelassen habe, da sie nicht sehr beliebt zu sein scheinen (z. B. EarlGray, Googles Framework für iOS-Automatisierung), und sie sind höchstwahrscheinlich sowieso Wrapper der in der Tabelle aufgeführten Technologien (z. B. Selendroid oder einer der Cloud-basierten mobilen Testautomatisierungsanbieter).

Name

Maintainer

Hauptfeatures

Unterstützte native Plattformen

Produktseite

Espresso

Google

Googles Standard-Test-Framework

Android

https://developer.android.com/training/testing/espresso

XCUITest

Apple

Apples Standard-Test-Framework

iOS / macOS

https://developer.apple.com/documentation/xctest/user_interface_tests

Appium

OpenJS Foundation / Open-source (Apache-2.0-Lizenz)

Unterstützt alle gängigen Plattformen

Android, iOS, macOS, Windows, Roku, tvOS, Android TV

https://appium.io/docs/en/latest/

Detox

Wix.com / Open-source (MIT)

Eng gekoppelt mit der React-Native-Architektur

Android, iOS

https://wix.github.io/Detox/

Maestro

Mobile.dev / Open-source (Apache 2.0-Lizenz)

Aufgrund der Implementierung von *.yaml-Dateien als Testdateiformat ist es wahrscheinlich das müheloseste mobile Testautomatisierungs-Framework

Android, iOS

https://maestro.mobile.dev/

Überblick über Appium-basierte Frameworks

Aus der obigen Liste kann Appium als das umfassendste und daher komplizierste Framework von allen betrachtet werden. Kurz gesagt besteht es aus vier grundlegenden Elementen: Appium Core, Drivers, Clients und Plugins.

Wir werden nicht im Detail darauf eingehen, was jedes Element bedeutet, aber um euch ein besseres Verständnis davon zu geben, welche Technologien vom Appium-Framework unterstützt werden, hier eine Liste der sogenannten Clients:

Name

Technologie

Produktseite

WebdriverIO

JavaScript (Node.js)

https://webdriver.io/

Appium Python Client

Python

https://github.com/appium/python-client

Appium Java Client

Java

https://github.com/appium/java-client

AppiumLib

Ruby

https://github.com/appium/ruby_lib

Appium .NET Client

C#

https://github.com/appium/dotnet-client/

Szenariobasierter Leitfaden zur Auswahl von mobilen Test-Frameworks

Wenn ihr eine der wichtigsten Entscheidungen im Kontext einer Teststrategie treffen müsst – nämlich die Wahl eines Frameworks zur Automatisierung mobiler End-to-End-Tests –, ist die Entscheidung ziemlich kompliziert, da sie von vielen Faktoren abhängt.

Machen wir ein kleines Gedankenexperiment und versuchen, einige mögliche Szenarien zu beschreiben, die euch bei der Entscheidung helfen sollen.

Kurzfassung:

• Wenn Entwickler native Entwicklungstools verwenden und Grey-/White-Box-End-to-End-Tests pflegen möchten und/oder ihr ein MVP erstellt: Espresso (für Android) / XCUITest (für iOS)
• Wenn ihr ein MVP entwickelt und nur UI-Tests benötigt (ohne physische iOS-Geräte und mit begrenzten Scripting-Möglichkeiten): Maestro
• Wenn ihr eine plattformübergreifende React-Native-Anwendung entwickelt und die Test-Scripting-Erfahrung mit Large Language Models verbessern möchtet: Detox
• Für langfristige Projekte, die stabile Lösungen erfordern: Appium-basierte Plattformen

Szenario 1: Nur Android oder iOS

Das erste Szenario ist ein Beispiel für wahrscheinlich frühe Entwicklungsphasen (z. B. Seed-Phase eines Startups), wenn der Fokus nur auf einer mobilen Plattform liegt. Das bedeutet, dass die natürliche Wahl entweder Espresso (für Android) oder XCUITest (für iOS) sein sollte.

Es könnte jedoch andere Dinge zu berücksichtigen geben, wie:

Ressourcenbeschränkte Umgebungen:

Wenn die Anwendung beispielsweise unter einem engen Zeitplan und/oder Budget entwickelt wird und die Entwickler einfach keine Zeit haben, die End-to-End-Test-Suites zu pflegen, kann die Wahl komplexer Espresso- oder XCUITest-Frameworks zu einer Katastrophe führen.

In dieser Art von Umgebung würde ich empfehlen, Maestro zu verwenden, da es das unkomplizierteste zu sein scheint und nicht zu viel Zeit und Aufwand für die Pflege von Test-Suites und Konfigurationen erfordert.

Zukunftssicherung für langfristige Projekte:

Wenn die Zeit- und Budgetbeschränkungen eures Projekts euch nicht nachts wachhalten, solltet ihr wahrscheinlich etwas mehr über den potenziellen Entwicklungspfad nachdenken.

Ich möchte betonen, dass wir Over-Engineering vermeiden sollten, aber andererseits ist es auch wichtig, ein Framework zu wählen, das wir in einer reiferen Testumgebung verwenden können. Mit einer reiferen Testumgebung meine ich Dinge wie automatisierte Testdatengenerierung und -bereinigung (die mit dem API-basierten Modell erreicht werden kann) oder die Integration in bestehende CI/CD-Pipelines. Und natürlich möchten wir, dass diese Dinge relativ einfach zu implementieren sind.

Zusammenfassend: Wenn ihr sicher seid, dass euer Projekt vollständig Android- oder iOS-basiert ist, die Entwickler diejenigen sind, die die Test-Suites schreiben und pflegen werden, und ihr nicht plant, es auf die entgegengesetzte Technologie auszuweiten, würde ich empfehlen, Espresso oder XCUITest zu verwenden, da diese die meisten Lösungen bieten, die an eure bestehende Codebasis angepasst sind. Andernfalls würde ich zu den Appium-basierten Lösungen neigen, da sie viel erweiterbarer sind und in Black-Box-Umgebungen verwendet werden können.

Szenario 2: Android und iOS

Meistens wollen Unternehmen ein breiteres Publikum ansprechen. Da Android einen Marktanteil von ~72 %* hat und iOS-Nutzer ~28 %* ausmachen, zielen die meisten Unternehmen auf beide Plattformen.

💡 Daten zum Stand 31.12.2024 von https://gs.statcounter.com/os-market-share/mobile/worldwide

Dieses Szenario ist – zumindest aus meiner Perspektive – in Bezug auf die Dinge, die vor einer fundierten Entscheidung berücksichtigt werden müssen, viel komplexer.

Separate Entwicklungsteams für Android und iOS

Wenn eure Anwendung von separaten Teams mit nativen Entwicklungstools (d. h. Android Studio und/oder Xcode) entwickelt wird, könnt ihr wahrscheinlich Espresso und XCUITest für End-to-End-Tests integrieren. Ich möchte jedoch darauf hinweisen, dass das möglicherweise eine suboptimale Lösung ist, da andere Frameworks es euch ermöglichen, beide Plattformen mit denselben Testskripten zu testen.

Für die in diesem Unterszenario genannte Situation würde ich also vorschlagen, Espresso und XCUITest für kleinere Tests (sozusagen Komponententests) zu verwenden, die von den Entwicklern selbst gepflegt werden, und umfassendere Frameworks für End-to-End-Tests zu integrieren (d. h. Appium oder Maestro).

Plattformübergreifende Entwicklung

Wie in der Tabelle im Abschnitt „Überblick über Entwicklungs-Frameworks” zu sehen ist, gibt es viele mögliche Frameworks zur Entwicklung plattformübergreifender Anwendungen. Die meisten Frameworks unterstützen alle Plattformen (Mobile, Web und Desktop), aber bei der mobilen Entwicklung konzentrieren wir uns hauptsächlich auf Android und iOS.

Um herauszufinden, welches Framework wir zum Schreiben und Pflegen mobiler End-to-End-Tests wählen sollten, müssen wir die möglichen Anforderungen und Rahmenbedingungen leider noch weiter unterteilen.

Wenn ihr wirklich keine Zeit habt, Test-Suites zu pflegen, und deshalb etwas Einfaches braucht, das sich fast mühelos schreiben und pflegen lässt, würde ich Maestro empfehlen.

Wenn ihr SDET oder erfahrener Test Automation Engineer seid, wollt ihr möglicherweise eher zu Appium-basierten Tools tendieren, da Appium euch alle Vorteile der mobilen Testautomatisierung sowie die Freiheit bietet, das gesamte Testautomatisierungs-Framework selbst zu konfigurieren. Ich sage nicht, dass Maestro das nicht kann, aber lest dazu die Nachbetrachtung zu Maestro.

Plattformübergreifende Entwicklung mit React Native

Das Tool, das ich noch nicht erwähnt habe, ist Detox. Das liegt daran, dass Detox speziell für Grey-Box-End-to-End-Tests für React Native entwickelt wurde. Ich würde empfehlen, es auszuprobieren, wenn ihr eine React-Native-Anwendung entwickelt, besonders angesichts der Tatsache, dass es das erste bekannte Framework ist, das Large Language Models zum Schreiben von Tests in natürlicher Sprache integriert.

Wenn ihr und euer Team jedoch Anwendungen für externe Kunden (sogenannte Enterprise-Anwendungen) entwickeln, die stabile Tools erfordern, würde ich dringend empfehlen, Appium-basierte Tools zu verwenden, da diese viel besser dokumentiert sind und viel größere Communities um sich herum haben.

Szenario 3: Android, iOS, Web und mehr

Das letzte Szenario, über das wir sprechen werden, ist native mobile Entwicklung in Kombination mit einer anderen Version der App. Das ist paradoxerweise das einfachste von allen.

Appium.

Es gibt schlicht keine andere Lösung, die es euch ermöglichen würde, auf allen verfügbaren Plattformen zu testen.

Natürlich könnt ihr auch Maestro für mobile Tests und Playwright für Web-Tests kombinieren. Oder Detox für Mobile, Appium für Smart-TV und Selenium für Web, wenn ihr das wollt. Es scheint nur keine gute Idee zu sein, besonders da einige der Appium-basierten Frameworks es euch ermöglichen, ein einzelnes Testskript zu erstellen, das sequentiell auf mehreren Plattformen läuft.

WebdriverIO ermöglicht es euch beispielsweise, etwas auf einem mobilen Gerät zu tun, dann zu einer separaten Webanwendung zu wechseln, um Werte zu ändern/zu überprüfen, und dann weitere Aktionen auf einem anderen mobilen Gerät durchzuführen.

Nachbetrachtung zu Maestro

Ich hatte das Gefühl, dass Maestro am Ende wie eine großartige Lösung erscheinen könnte, was es in manchen Fällen sein kann. Ich möchte euch aber auch dazu bringen, über mögliche Nachteile nachzudenken, wenn ihr euch dafür entscheidet.

Maestro gibt euch die Möglichkeit, das Testautomatisierungs-Framework zu konfigurieren (z. B. JavaScript-Code auszuführen), aber da es für eine bestimmte Architektur geschrieben wurde, ist es eher ein Add-on zu den Standard-YAML-Flow-Dateien als etwas anderes.

Eine weitere Sache, die man beim Thema Maestro im Hinterkopf behalten sollte, ist der Fall rund um die IP-Änderung bei Cypress im vergangenen Jahr. Kurz gesagt hat das Cypress-Team die Möglichkeit entfernt, zuvor kostenlose Drittanbieter-Services für Dashboards zu nutzen, und zwang Unternehmen damit faktisch auf die eigene Cloud-Plattform.

Diese Plattform ist nicht nur nicht kostenlos, sondern verhindert auch, dass Cypress dort verwendet werden kann, wo Verträge mit Kunden die Nutzung von Cloud-Plattformen aufgrund der DSGVO oder ähnlicher Gesetze ausdrücklich verbieten. Ich erwähne das, weil Maestro seine eigene Cloud-Plattform für die Ausführung von Tests namens Robin hat, und es möglich ist, dass ein ähnliches Szenario wie beim Cypress-Update auch bei Maestro eintreten könnte.

Entwicklung für das Apple-Ökosystem

Das Letzte, was ich hier erwähnen möchte, ist, dass ihr, wenn ihr Tests für das Apple-Ökosystem schreiben möchtet – nämlich iOS, iPadOS, macOS oder tvOS –, tatsächlich einen auf macOS basierenden Computer besitzen müsst (entweder ein MacBook, Mac Mini/Studio/Pro oder iMac), da ihr Xcode installiert haben müsst.

Der Grund ist einfach: Es enthält die Simulator-Anwendung, die es euch ermöglicht, eure Anwendung in einer virtuellen Umgebung auszuführen, und ist erforderlich, um Tests auf echten Geräten auszuführen. Ihr benötigt auch ein Apple-Konto, und wenn ihr eure Anwendung im AppStore veröffentlichen möchtet, müsst ihr euch für das kostenpflichtige Apple Developer Program anmelden.