Grundlagen zum Testen von Android-Apps

Auf dieser Seite werden die wichtigsten Grundsätze des Testens von Android-Apps beschrieben, einschließlich der zentralen Best Practices und ihrer Vorteile.

Vorteile von Tests

Tests sind ein wesentlicher Bestandteil der App-Entwicklung. Wenn Sie Ihre App regelmäßig testen, können Sie vor der Veröffentlichung die Richtigkeit, das funktionale Verhalten und die Nutzerfreundlichkeit Ihrer App überprüfen.

Sie können Ihre App manuell testen, indem Sie sie durchgehen. Dabei können Sie verschiedene Geräte und Emulatoren verwenden, die Systemsprache ändern und versuchen, jeden Nutzerfehler zu erzeugen oder jeden Nutzerablauf zu durchlaufen.

Manuelle Tests sind jedoch nicht gut skalierbar und es kann leicht passieren, dass Regressionen im Verhalten Ihrer App übersehen werden. Bei automatisierten Tests werden Tools verwendet, die Tests für Sie ausführen. Das ist schneller, wiederholbarer und Sie erhalten in der Regel früher im Entwicklungsprozess mehr umsetzbares Feedback zu Ihrer App.

Testarten in Android

Mobile Apps sind komplex und müssen in vielen Umgebungen gut funktionieren. Daher gibt es viele Arten von Tests.

Betreff

Je nach Betreff gibt es beispielsweise verschiedene Arten von Tests:

  • Funktionstests: Macht meine App das, was sie soll?
  • Leistungstests: Macht sie das schnell und effizient?
  • Tests zur Barrierefreiheit: Funktioniert sie gut mit Diensten für die Barrierefreiheit?
  • Kompatibilitätstests: Funktioniert sie auf allen Geräten und API-Ebenen?

Umfang

Tests variieren auch je nach Größe oder Grad der Isolation:

  • Bei Unittests oder kleinen Tests wird nur ein sehr kleiner Teil der App überprüft, z. B. eine Methode oder Klasse.
  • Bei End-to-End-Tests oder großen Tests werden größere Teile der App gleichzeitig überprüft, z. B. ein ganzer Bildschirm oder ein Nutzerablauf.
  • Mittelgroße Tests liegen dazwischen und prüfen die Integration zwischen zwei oder mehr Einheiten.
Tests können klein, mittel oder groß sein.
Abbildung 1: Testumfänge in einer typischen Anwendung.

Es gibt viele Möglichkeiten, Tests zu klassifizieren. Der wichtigste Unterschied für App-Entwickler ist jedoch, wo Tests ausgeführt werden.

Instrumentierte Tests im Vergleich zu lokalen Tests

Sie können Tests auf einem Android-Gerät oder auf einem anderen Computer ausführen:

  • Instrumentierte Tests werden auf einem Android-Gerät ausgeführt, entweder auf einem physischen Gerät oder in einem Emulator. Die App wird zusammen mit einer Test-App erstellt und installiert, die Befehle einfügt und den Status liest. Instrumentierte Tests sind in der Regel UI-Tests, bei denen eine App gestartet und dann mit ihr interagiert wird.
  • Lokale Tests werden auf Ihrer Entwicklungsmaschine oder einem Server ausgeführt. Daher werden sie auch als Host-seitige Tests bezeichnet. Sie sind in der Regel klein und schnell und isolieren das zu testende Objekt vom Rest der App.
Tests können als Instrumentierungstests auf einem Gerät oder als lokale Tests auf Ihrem Entwicklungscomputer ausgeführt werden.
Abbildung 2: Verschiedene Arten von Tests je nachdem, wo sie ausgeführt werden.

Nicht alle Unittests sind lokal und nicht alle End-to-End-Tests werden auf einem Gerät ausgeführt. Beispiel:

  • Großer lokaler Test: Sie können einen Android-Simulator verwenden, der lokal ausgeführt wird, z. B. Robolectric.
  • Kleiner instrumentierter Test: Sie können überprüfen, ob Ihr Code gut mit einer Framework-Funktion funktioniert, z. B. einer SQLite-Datenbank. Sie können diesen Test auf mehreren Geräten ausführen, um die Integration mit mehreren Versionen von SQLite zu prüfen.

Beispiele

Die folgenden Code-Snippets zeigen, wie Sie in einem instrumentierten UI-Test mit der Benutzeroberfläche interagieren, indem Sie auf ein Element klicken und prüfen, ob ein anderes Element angezeigt wird.

Espresso

// When the Continue button is clicked
onView(withText("Continue"))
    .perform(click())

// Then the Welcome screen is displayed
onView(withText("Welcome"))
    .check(matches(isDisplayed()))

Compose UI

// When the Continue button is clicked
composeTestRule.onNodeWithText("Continue").performClick()

// Then the Welcome screen is displayed
composeTestRule.onNodeWithText("Welcome").assertIsDisplayed()

Dieses Snippet zeigt einen Teil eines Unittests für ein ViewModel (lokaler, Host-seitiger Test):

// Given an instance of MyViewModel
val viewModel = MyViewModel(myFakeDataRepository)

// When data is loaded
viewModel.loadData()

// Then it should be exposing data
assertTrue(viewModel.data != null)

Testfähige Architektur

Bei einer testfähigen App-Architektur folgt der Code einer Struktur, mit der Sie verschiedene Teile davon einfach isoliert testen können. Testfähige Architekturen haben weitere Vorteile, z. B. eine bessere Lesbarkeit, Wartbarkeit, Skalierbarkeit und Wiederverwendbarkeit.

Eine Architektur, die nicht testfähig ist, führt zu Folgendem:

  • Größere, langsamere und instabilere Tests. Klassen, die nicht mit Unittests getestet werden können, müssen möglicherweise mit größeren Integrationstests oder UI-Tests abgedeckt werden.
  • Weniger Möglichkeiten zum Testen verschiedener Szenarien. Größere Tests sind langsamer. Daher ist es möglicherweise unrealistisch, alle möglichen Zustände einer App zu testen.

Weitere Informationen zu Architekturrichtlinien finden Sie im Leitfaden zur App Architektur.

Ansätze zur Entkopplung

Wenn Sie einen Teil einer Funktion, Klasse oder eines Moduls vom Rest trennen können, ist das Testen einfacher und effektiver. Diese Vorgehensweise wird als Entkopplung bezeichnet und ist das wichtigste Konzept für eine testfähige Architektur.

Zu den gängigen Entkopplungstechniken gehören:

  • Eine App in Ebenen aufteilen, z. B. Präsentation, Domain und Daten. Sie können eine App auch in Module aufteilen, eines pro Funktion.
  • Vermeiden Sie es, Entitäten mit großen Abhängigkeiten wie Aktivitäten und Fragmenten Logik hinzuzufügen. Verwenden Sie diese Klassen als Einstiegspunkte für das Framework und verschieben Sie UI- und Geschäftslogik an einen anderen Ort, z. B. in eine Composable, ein ViewModel oder eine Domain-Ebene.
  • Vermeiden Sie direkte Framework-Abhängigkeiten in Klassen, die Geschäftslogik enthalten. Verwenden Sie beispielsweise keine Android-Kontexte in ViewModels.
  • Sorgen Sie dafür, dass Abhängigkeiten einfach ersetzt werden können. Verwenden Sie beispielsweise Schnittstellen anstelle konkreter Implementierungen. Verwenden Sie Dependency Injection, auch wenn Sie kein DI-Framework verwenden.

Nächste Schritte

Nachdem Sie nun wissen, warum Sie testen sollten und welche beiden Haupttypen von Tests es gibt, können Sie sich ansehen, was Sie testen sollten, oder sich über Teststrategien informieren.

Alternativ können Sie auch die Codelabs zum Testen durcharbeiten, wenn Sie Ihren ersten Test erstellen und durch Üben lernen möchten.