Grundlagen zum Testen von Android-Apps

Auf dieser Seite werden die wichtigsten Grundsätze für das Testen von Android-Apps beschrieben, einschließlich der wichtigsten 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. Sie können verschiedene Geräte und Emulatoren verwenden, die Systemsprache ändern und versuchen, alle Nutzerfehler zu generieren oder jeden Nutzerfluss zu durchlaufen.

Manuelle Tests skalieren jedoch schlecht und es kann leicht passieren, dass Regressionen im Verhalten Ihrer Anwendung übersehen werden. Bei automatisierten Tests werden Tools verwendet, die die Tests für Sie ausführen. Das ist schneller, wiederholbarer und liefert in der Regel früher im Entwicklungsprozess umsetzbareres Feedback zu Ihrer App.

Testtypen unter Android

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

Betreff

Je nach Thema gibt es beispielsweise verschiedene Arten von Tests:

  • Funktionstests: Funktioniert meine App wie vorgesehen?
  • Leistungstests: Ist das schnell und effizient?
  • Tests zur Barrierefreiheit: Funktioniert die Website gut mit Bedienungshilfen?
  • Kompatibilitätstests: Funktioniert die Funktion auf allen Geräten und API-Ebenen gut?

Aufgabenstellung

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

  • Bei Einheitstests oder kleinen Tests wird nur ein sehr kleiner Teil der App geprüft, z. B. eine Methode oder Klasse.
  • Mit End-to-End-Tests oder großen Tests können größere Teile der App gleichzeitig überprüft werden, z. B. ein gesamter Bildschirm oder ein Nutzerfluss.
  • Mitteltests liegen dazwischen und prüfen die Integration zwischen zwei oder mehr Einheiten.
Tests können klein, mittel oder groß sein.
Abbildung 1: Testumfang in einer typischen Anwendung

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

Instrumentierte und lokale 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 einem emulierten Gerät. Die Anwendung wird zusammen mit einer Testanwendung 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 damit interagiert wird.
  • Lokale Tests werden auf Ihrem Entwicklungscomputer oder einem Server ausgeführt und werden deshalb auch als hostseitige Tests bezeichnet. Sie sind in der Regel klein und schnell und isolieren das Testobjekt vom Rest der App.
Tests können als instrumentierte Tests auf einem Gerät oder als lokale Tests auf Ihrem Entwicklungscomputer ausgeführt werden.
Abbildung 2: Unterschiedliche Arten von Tests je nach Ausführungsort

Nicht alle Unit-Tests 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 lokal ausgeführten Android-Emulator wie Robolectric verwenden.
  • Kleiner instrumentierter Test: Sie können prüfen, ob Ihr Code gut mit einer Framework-Funktion wie einer SQLite-Datenbank funktioniert. Sie können diesen Test auf mehreren Geräten ausführen, um die Integration mit mehreren SQLite-Versionen zu prüfen.

Beispiele

In den folgenden Snippets wird gezeigt, 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()))

Benutzeroberfläche erstellen

// 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 Einheitstests für ein ViewModel (lokaler, hostseitiger 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)

Testbare Architektur

Bei einer testbaren App-Architektur folgt der Code einer Struktur, mit der Sie verschiedene Teile davon einfach einzeln testen können. Testbare Architekturen haben weitere Vorteile, z. B. bessere Lesbarkeit, Verwaltbarkeit, Skalierbarkeit und Wiederverwendbarkeit.

Eine Architektur, die nicht testbar ist, erzeugt Folgendes:

  • Größere, langsamere, instabilere Tests. Bei Klassen, für die keine Einheitentests durchgeführt werden können, müssen möglicherweise größere Integrations- oder UI-Tests durchgeführt werden.
  • Weniger Möglichkeiten zum Testen verschiedener Szenarien. Größere Tests sind langsamer. Daher ist es möglicherweise unrealistisch, alle möglichen Status einer App zu testen.

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

Ansätze zur Entkopplung

Wenn Sie Teile einer Funktion, Klasse oder eines Moduls aus dem Rest extrahieren können, ist das Testen einfacher und effektiver. Diese Praxis wird als Entkopplung bezeichnet und ist das für eine testbare Architektur wichtigste Konzept.

Zu den gängigen Entkopplungstechniken gehören:

  • Eine App in Ebenen wie Präsentation, Domain und Daten aufteilen. Sie können eine App auch in Module aufteilen, jeweils eines pro Funktion.
  • Fügen Sie Entitäten mit vielen Abhängigkeiten wie Aktivitäten und Fragmenten keine Logik hinzu. Verwenden Sie diese Klassen als Einstiegspunkte in das Framework und verschieben Sie die UI und Geschäftslogik an andere Stellen, z. B. in eine Composable-, ViewModel- oder Domainebene.
  • Vermeiden Sie direkte Framework-Abhängigkeiten in Klassen mit Geschäftslogik. Verwenden Sie beispielsweise keine Android-Kontexte in ViewModels.
  • Sorgen Sie dafür, dass Abhängigkeiten leicht ersetzt werden können. Verwenden Sie beispielsweise Schnittstellen anstelle von konkreten Implementierungen. Verwenden Sie die Abhängigkeitsinjektion, auch wenn Sie kein DI-Framework verwenden.

Nächste Schritte

Nachdem Sie nun wissen, warum Sie Tests durchführen sollten und welche beiden Haupttypen es gibt, können Sie sich weiterführende Informationen dazu ansehen, was Sie testen sollten oder sich über Teststrategien informieren.

Wenn Sie stattdessen Ihren ersten Test erstellen und durch praktisches Lernen lernen möchten, sehen Sie sich die Codelabs zum Testen an.