Android Testing

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.

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.

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.

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.