© 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 Annahme, dass hier der Kernaufwand liegen sollte. Häufig wird versucht, möglichst viele Hardwarevarianten abzudecken. Die Android-Entwicklung unterscheidet sich in diesem Punkt allerdings nicht so stark wie vermutet von Webanwendungen. Klassische Webanwendungen müssen ebenfalls viele verschiedene Browservarianten unterstützen. Da es unmöglich ist, alle Kombinationen abzudecken und diese Tests sehr aufwändig sind, gilt es gut abzuwägen, was zwingend über Oberflächentests abgedeckt sein muss.

Gekrönt wird diese Pyramide durch manuell ausgeführtes exploratives Testen (Abb. 1). Bei einigen komplexen Konstellationen lohnt sich keine Automatisierung, weil sie sehr aufwändig wäre und bestimmte Fehlerarten nur sehr selten auftreten. Diese Art von Fehlern sollte explorativ untersucht werden.

gruczel_testen_1.tif_fmt1.jpgAbb. 1: Testpyramide

Ein weiteres Model, das helfen kann, die Tests zu strukturieren, sind die agilen Testquadranten nach Crispin/Gregory (Abb. 2) [1]. Hier werden verschiedene Testtypen auf den Achsen funktional (fachlich)/nicht funktional (technisch) und teamunterstützend / Geschäftstauglichkeit eingeordnet. Dabei lassen sich die teamunterstützenden und nicht technischen Tests zumeist vollständig automatisieren (Q1). Es handelt sich hierbei zum Beispiel um Unit Tests. Die Tests, welche die Geschäftstauglichkeit testen und teamunterstützend sind, werden zumeist mithilfe von Tools manuell ausgeführt (Q4). Dabei handelt es sich zum Beispiel um Performance. Die Abnahme von konkreten Geschäftsfällen (Q2) ist zumeist über Oberflächentests zu automatisieren. Schnell werden diese Tests aber instabil und komplex. Hier gilt es, eine Abwägung zwischen Automatisierung und manuellem Test zu ziehen. Quadrant 3 ist die Menge der manuell und explorativ ausgeführten Tests, um die Geschäftstauglichkeit in Spezialsituationen zu prüfen. Auch dieses Modell zeigt auf, dass sich nicht in allen Fällen eine Automatisierung lohnt. Der Hauptfokus der Automatisierung liegt auf den Unit Tests. Für die anderen Quadranten sollten aber auch Konzepte vorhanden sein.

gruczel_testen_2.tif_fmt1.jpgAbb. 2: Testquadranten nach Crispin/Gregory

Welche Werkzeuge brauche ich zur Ausführung der Tests?

Die Tests lassen sich auf einem Gerät oder auch im Emulator ausführen; einfache Unit Tests auch ohne Devices. Der im SDK ausgelieferte Emulator ist nach der regulären Installation lähmend langsam. Hier bieten sich ein paar Optionen zur Optimierung an.

Eine Option ist, den Emulator zu beschleunigen. Hierzu können prozessorspezifische virtuelle Beschleunigungen aktiviert werden. So kann zum Beispiel HAXM (Intel Hardware Accelerated Execution Manager) [2] genutzt werden, wenn der Rechner mit Intel-Prozessoren bestückt ist. Dazu muss dann im AVD Manager (An­droid Virtual Devices) ein x86-System für das virtuelle Device gewählt werden. Zudem kann die GPU-Emulation aktiviert werden (Use Host GPU), um das Rendering zu beschleunigen. Dies hat Nebenwirkungen. Zum Beispiel können keine Snapshots vom Emulatorzustand erstellt werden, um den Bootprozess zu verkürzen. Beide Maßnahmen beschleunigen den Emulator merklich. Wie dies funktioniert, ist in der Android-Dokumentation beschrieben [3].

Eine weitere Option ist, einen alternativen Emulator zu nutzen. Eine Alternative ist der kostenpflichtige Emulator Genymotion [4]. Dieser bedarf eines gewissen Installationsaufwands. So enthalten die von Genymotion ausgelieferten Images zum Beispiel keine Playservices. Sie können nachinstalliert werden. Nach dem initialen Aufwand bietet Genymotion aber erweiterte Möglichkeiten und höhere Geschwindigkeiten, was den initialen Aufwand häufig mehr als ausgleicht. Genymotion bietet neben der höheren Geschwindigkeit auch bequemere Möglichkeiten, GPS, Ladezustand, Orientierung und dergleichen zu simulieren.

Unit Tests

Unit Tests bilden die Basis einer jeden Entwicklung. Sie stellen die höchste Menge dar und geben am genauesten über Fehler Auskunft. Sie sind in dem Pyramidenmodell die unterste Schicht und in dem Quadrantenmodell der Quadrant 1. Es handelt sich um Tests, die nur eine Kl...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang