© Excellent backgrounds/Shutterstock.com
Teil 2: Testen einer App

Der fehlende Android-Guide


Die offizielle Android-Dokumentation ermöglicht einen einfachen Einstieg in die Entwicklung von Android-Apps. Open-Source-Frameworks oder Tools anderer Anbieter sind hier nicht mit einbezogen, ebenso fehlen Hinweise auf Design-Patterns, die unschöne Designentscheidungen im Android-SDK ausgleichen könnten. Im letzten Teil der Reihe haben wir betrachtet, welche Konzepte und Werkzeuge bei dem Aufbau einer sauberen Architektur einer Android-App helfen können. Dieser Teil betrachtet wichtige Testkonzepte und zeigt dazu einige Beispiele.

Die Testdiskussion in der Android-Welt reduziert sich häufig auf eine Diskussion über Tools. Die Anzahl an Werkzeugen für die Ausführung von Oberflächentests steigt dabei ständig an. In vielen Fällen wird nicht hinterfragt, welche Testarten für die verschiedenen Problemtypen hilfreich sind. Hier helfen zwei einfache Modelle, um eine bessere Übersicht zu bekommen.

Die Testpyramide verdeutlicht eine gesunde Verteilung der verschiedenen Testarten. Tests, die nur Methoden oder Klassen testen, laufen am schnellsten und geben somit auch am schnellsten Feedback. Diese Art von Tests werden Unit Tests genannt. Sie können die Fehlerstelle am genausten aufzeigen. Diese Art von Test sollte das Fundament der Teststrategie sein. Wenn die Anwendungsschichten vernünftig voneinander abgekapselt sind, lässt sich mithilfe dieser Testart ein Großteil der Businesslogik völlig unabhängig von Geräteeigenschaften abdecken. Diese Art von Tests sollte vollständig automatisiert werden und bietet sich für Test-driven-Development (TDD) bestens an.

Die nächste Stufe von automatischen Tests sind die Integrationstests. Sie sind dazu geeignet, das Zusammenspiel von verschiedenen Klassen und Services zu prüfen. Aufgrund der höheren Komplexität und Abhängigkeiten laufen diese Tests häufig länger. Somit ist das Feedback langsamer. Deshalb sollte die Testmenge hier geringer ausfallen.

Genau wie in der klassischen Java-Welt, ist es mit diesen beiden Testarten, verschiedenen Mocking-Frameworks und einer vernünftigen Architektur möglich, den Großteil der Logik abzudecken. Über diesen Schichten liegen Oberflächentests. Diese sind am anfälligsten und am langsamsten. Die Ausführung unterscheidet sich zudem geräteabhängig. Von dieser Sorte sollte es die geringste Anzahl an automatisierten Tests geben. Es kann leider leicht passieren, dass diese Testsorte dominierend wird. Die hohe Anzahl an verschiedenen Herstellern, Auflösungen und Gerätegrößen führt leicht zu der Anna...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang