Android Testing

Marco Feltmann · 3. April 2013

Moin,

ich werd irre mit Android. Mal wieder.
Nach etlichem Hin und Her habe ich jetzt endlich ein paar Modellklassen fertig (so 15 Stück), die ich gern unverändert lassen möchte.
Natürlich werden sich diese ganz gewaltig ändern, liegt ja in der Natur von Modellen.

Beim bösen Feind aus Cupertino läuft das alles ganz flüssig, die legen mir automatisch eine Testklasse an, ich schmeiß da meinen Scheiß rein, klicke auf 'Testing' und – et voilá – fertig.

Bei Android bin ich offenbar nicht einmal fähig einen einzigen Unit Test für ein einziges Modell anzulegen. Das Internet ist voll von Tutorials, mit denen ich meine Activity getestet bekomme – was mir allerdings erst mal völlig wurscht ist, weil die alles Andere als fertig ist.

Die Testing Fundamentals sind ebenfalls alles Andere als aufschlussreich. So sehe ich zwar, dass mir ein 'TestCase' reichen sollte, nur sagt mir niemand, wie ich das alles verdrahtet bekomme oder wie ich Selbigen starten kann.

Und wenn ich dann noch Informationen wie Speicherverbrauch oder Zeitübersicht haben möchte, bin ich völlig aufgeschmissen.

Hat jemand für mich einen Tipp, wie ich ziemlich zielgerichtet zumindest meine 15 Modelle getestet bekomme?
Ohne ActivitySchnickSchnackGelöt, bitte.

UweApps · 6. April 2013

Hallo Lucas,

zunächst brauchst du natürlich ein Test-Projekt, normalerweise sollte dir die IDE ein "Android Test Project" als Auswahl für ein neues Projekt anbieten. Das ist dann eine fast normale App, der das zu testende App-Projekt zugeordnet wird. Dies Test-Projekt muss aber über "Android JUnit Test" gestartet werden - nicht als "Android Application", ist ja keine App.

In dem Projekt musst du die Klassen dann selber anlegen - automatische Test-Klassen- oder -Methoden-Erzeugung in Android hab ich bisher nicht gesehen.

Wenn es um Tests für einfache Klassen geht, dann ist TestCase die Klasse, von der du erben solltest. Und da läuft eigentlich alles wie bei normalem JUnit-Testing. Vielleicht noch MoreAsserts für etwas mehr Komfort.

Wenn du einen Context brauchst (z.B. Datenbank), dann ist AndroidTestCase deine Eltern-Klasse.

Und falls du eine Activity oder App testen willst, dann ist ActivityInstrumentationTestCase2<DeineKlasse> nötig. Um mit der UI umzugehen, empfehle ich dringend Robotium, da die UI-Zugriffe sonst etwas unhandlich sind.

Falls du später mal gucken willst, ob deine Tests auch den Code abdecken - dafür ist Emma bereits in dem Android-SDK eingebaut.

Speicherverbrauch und Timing sind eigentlich über andere Klassen abzurufen - musst halt gucken, was du auswerten willst.

Viel Erfolg!
Uwe

Marco Feltmann · 7. April 2013

Hi UweApps,

danke für die Tipps.
Das mit den Testmodulen hatte ich so bereits gesehen, wunderte mich nur, dass ich ausschließlich mein Demoprojekt als 'zu testen' auswählen konnte.
Scheint darin begründet zu liegen, dass das Default-Testprojekt unbedingt ein ActivityTest sein will. +seufz+

Wie dem auch sei.
Nach längerem Hin und Her habe ich zumindest ein paar lauffähige UnitTests erstellen können.
Danke für deine Hilfestellungen.

braindead · 16. Januar 2014

Zitat von Lucas de Vil

Moin,
Bei Android bin ich offenbar nicht einmal fähig einen einzigen Unit Test für ein einziges Modell anzulegen. Das Internet ist voll von Tutorials, mit denen ich meine Activity getestet bekomme – was mir allerdings erst mal völlig wurscht ist, weil die alles Andere als fertig ist.

Hallo,

nur als Tipp: Man schreibt Test eigentlich bevor man anfängt etwas zu implementieren. Nicht wenn es schon implementiert ist.

Java

Car car = new Car();
car.drive(10);


assertEquals(10, car.getDrivenDistance());

und dann überlegst du dir wie du drive implementieren musst damit es genau das macht. Und zwar nur das

Marco Feltmann · 17. Januar 2014

Zitat von braindead

nur als Tipp: Man schreibt Test eigentlich bevor man anfängt etwas zu implementieren.

Ich persönlich fasse das mehr als vernünfteln denn als Tipp auf.
Im Prinzip bin ich mit dem Test Driven Development vertraut. Und was testet man zunächst bevor man sich überhaupt an so etwas wie das User Interface setzt? Das Modell. Alle Objekte, die irgendwas tun ohne wirklich etwas anzuzeigen. Und das hatte ich zu dem Zeitpunkt einfach noch nicht herausgefunden.

Davon abgesehen halte ich vom echten TDD nicht allzu viel:
Kostet viel zu viel Zeit - Statt schon mal zu implementieren definiere ich irgendwelche Methoden-Stubs, schraube meinen Test drum herum, prüfe ob die Tests auch ja greifen und richtig sind (meist hat sich dort schon ein Fehler eingeschlichen, der am Ende noch mal Zeit kostet), implementiere meine Methoden in der Klasse und habe da ungefähr 20% mehr Zeit für etwas investiert, das überhaupt nicht notwendig gewesen wäre.

Zusätzliche Komplexität - Sind die Klassen nicht so simpel, steigt auch die Komplexität der Testszenarien gewaltig an. Man testet ja nicht nur, was alles geht, man testet auch, was alles nicht gehen soll. Und es kann beispielsweise echt hart werden zu testen, ob und wie gut sich dein Objekt während Multithreading verhält. (z.B. 'Ist mein Singleton auch dann ein Singleton, wenn von mehreren Threads auf das Objekt zugegriffen wird?')

Auswirkungen auf das Design - Wenn das Design nicht zu Beginn steht oder sich auf täglicher Basis ändert, bist Du permanent dabei Deine Tests umzuschreiben um unnötige nicht benutzte Methoden wieder rauszuschmeißen. Und was war das oberste Gebot bei den Tests? Never touch a passing test.
Dir stehen also 'Finger weg vom funktionierenden Test' und 'Weg mit nicht benutzten Methoden' gegenüber. Blöde Situation.

Laufende Optimierungen - Sollte Deine Klasse Optimierungen unterzogen werden, die sich nicht vermeiden lassen (Beispielsweise sich ändernde Algorithmen) musst Du wieder an Deinen Tests herumschrauben.

Aus diesen Gründen (wir nutzen hier hauptsächlich Scrum und da ändert sich ja per Definition immer alles) bin ich vom richtigen echten TDD weg.

braindead · 17. Januar 2014

Hey,

all das was du aufzählst sind genau die Gründe warum man Tests schreibt. Wenn ein Projekt genügend komplex ist, dann sind Tests unerlässlich. Natürlich ist es für den Entwickler erstmal nervig Tests zu entwickeln, aber gerade wenn im Team entwickelt wird und man nicht jede Komponente der Software genau kennt, dann weiß man im Zweifel nicht ob die Änderung irgendwas kaputt macht das nicht sofort auffällt.

Die Zeit die zum Entwickeln der Tests draufgeht ist mehr als gut angelegt. Stell dir einfach mal vor die lieferst eine Software zum Kunden aus und alles funktioniert wie es soll. Nach einem Jahr kommt der Kunde und möchte etwas geändert haben. Das implementierst du und lieferst es wieder aus. Und plötzlich passieren an einer anderen Stelle Fehler. Z.B. werden Termine nicht mehr richtig gebucht oÄ. Und der Kunde verliert, auf Grund deines Fehlers, hunderttausende oder sogar millionen von Euro. Der kommt 1. nicht wieder und 2. wird er dich wohl auf Schadensersatz verklagen.

Das ist natürlich ein drastisches Beispiel. Aber es reicht ja auch schon wenn durch fehlende Tests ein Entwickler eine Woche auf die Suche nach einem Bug geht. Das kostet dann halt auch mal 4000€. Wenn sowas bei jedem Release vorkommt dann macht dein Chef sich auch mal Gedanken was du da so treibst

Am besten hat man gute Tests und ein Build-Script das vorher sämtliche Tests abarbeitet und bei Fehlern den Dienst verweigert. So minimiert man Fehler drastisch.

Marco Feltmann · 17. Januar 2014

Du beschreibst Testszenarien. Ich nutze Testszenarien.
Ich verweigere mich lediglich dem TDD.

Und in Deinem gesamten Post finde ich kein Argument, dass mich zum TDD antreibt.

Android Testing

Jetzt mitmachen!

Teilen