Test-driven Development mit Android und Maven

Grüne Männchen testgetrieben


Wer in gewöhnlichen Java-Enterprise-Projekten eine Infrastruktur für Test-driven Development aufbaut, kann auf langjährig bewährte Werkzeuge zurückgreifen. In Android-Projekten sieht die Sache jedoch anders aus: Da die Plattform jung und nicht pures Java ist, begegnet man auf dem Weg zur ausreichenden Test Coverage einigen Stolpersteinen.

Die testgetriebene Entwicklung ist eine der Grundlagen für agile Praktiken, wie Continuous Integration (Kasten). Der Entwickler erstellt zuerst die Unit Tests und beginnt danach mit der Implementierung. Diese gilt als abgeschlossen, sobald die Unit Tests erfolgreich durchlaufen. Die Konsequenzen daraus sind:

  • Die Entwicklung der Schnittstellen aus Test- bzw. Kundensicht führt zu besserem Design.

  • Die konsequente Abdeckung des Quellcodes durch Unit Tests macht implizite Annahmen des Entwicklers explizit und überprüfbar. Die Abhängigkeit vom ursprünglichen Entwickler und das Risiko von Änderungen sowie Refaktorisierungen werden reduziert, Collective Code Ownership wird möglich.

Continuous Integration

Continuous Integration [1] ist eine der Hauptvoraussetzungen für den Qualitäts- und Produktivitätsschub der agilen Methode. Sie geht u. a. zurück auf Martin Fowlers Zitat „If it hurts, do it more often“ [2]. Das heißt schwierige manuelle Prozesse werden automatisiert und so oft ausgeführt, bis sie einfache Routine werden. Die wichtigsten Bestandteile dabei sind:

  • Versionsverwaltung

  • Abdeckung des Quellcodes durch Unit Tests

  • Automatisierter Build

  • Automatisierte Verteilung

  • Kurze Test- und Feedback-Zyklen

Warum für Android-Apps?

Es liegt in der Natur von Android als Plattform für mobile Endgeräte, dass sich der Umfang von Android-Apps im Gegensatz zu beispielsweise Enterprise-Software in Grenzen hält. Dies hat folgende Ursachen:

  • Die knappen Hardwareressourcen von mobilen Endgeräten setzen dem Spielraum der Entwickler enge Grenzen.

  • Android-Apps fokussieren sich auf eine Hauptaufgabe, das reduziert die Anzahl der Bildschirmmasken.

  • Die beschränkte Displaygröße reduziert wiederum den Umfang der einzelnen Bildschirmmasken.

  • Die Geschäftslogik wird meistens auf einem ­Backend-System ausgeführt.

  • Das komfortable Android-API senkt den Bedarf an Boilerplate-Code.

Dies führt im Entwickleralltag nun leider dazu, dass Themen wie Build-Prozess und Unit-Test-Abdeckung zu wenig Beachtung finden, weil ihre Bedeutung unterschätzt wird. Da die Komplexität bei Android-Apps aber verborgen in der Fragmentierung der Plattform und den hohen Benutz...

Neugierig geworden?

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