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 durch sie navigieren. 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 sind jedoch nur bedingt skalierbar und es kann leicht passieren, dass Sie Rückschritte im Verhalten Ihrer App übersehen. 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?
  • Barrierefreiheitstests: Funktioniert die App 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:

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

Es gibt viele Möglichkeiten, Tests zu klassifizieren. Der wichtigste Unterschied für App-Entwickler ist jedoch, 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 App wird zusammen mit einer Test-App erstellt und installiert, die Befehle einschleust 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. Sie werden daher 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-Simulator 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 zum Schreiben

// 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 nicht testbare Architektur führt zu Folgendem:

  • 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 einen Teil einer Funktion, Klasse oder eines Moduls aus dem Rest extrahieren können, sind die Tests 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 konkreter 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 Ihren ersten Test erstellen und durch Ausprobieren lernen möchten, sehen Sie sich die Codelabs an.