Zeitplanung für JUnit-Tests?

[Verjigorm]

Hallo,

ich habe grad folgendes Problem:

Ich soll 250 JUnit Tests realisieren und planen, wie lange diese dauern werden.
Die zu testenden Funktionen sind alle nicht sehr komplex. Um die Zeit zu schätzen habe ich mal einige Tests gemacht und auf die Uhr geschaut.
Für eine grobe Zeitschätzung hätte ich 20min pro JUnit-Test getippt.
TestFunktion anlegen, Test ausarbeiten, testen, eventuell Bugs fixen, Retest etc.

Nun ist das meinem Chef ddefinitiv zu lange für "simple" JUnit-Tests.
Meint ihr die Schätzung ist so ok, gibts da irgendwo irgendwelche groben Vorgaben/Guides/Planungen dazu? Oder habt ihr eigene Erfahrungen damit gemacht?

mfg Verjigorm

 

[bygones]

redest du hier vom alleinigen ausführen ?

dann sollten wir eher von 250sekunden reden.

redest du hier vom schreiben ?

dann hängst es von deinem Testkönnen, deiner Nähe zum testenden Code und der Testbarkeit des Codes ab.

da würde ich dann schonmal mann-Tage veranschlagen

Nun ist das meinem Chef ddefinitiv zu lange für "simple" JUnit-Tests.

gibt ein paar möglichkeiten:

a) Chef hat keine Ahnung von Tests und für ihn ists einfach n simples gehacke
b) der Code ist so trivial dass Tests eher übertesten
c) der Code ist so gut geschrieben, dass er hervorragend testbar ist, dann ists wirklich simpel
d) Chef hat keine Ahnung von Tests und der Code ist typisches Wirrwarr.... dann brauchsts es nicht mal versuchen.

Aus Erfahrung ists c) schonmal nicht

Daher - eine Abschätzung wielange das dauert hängt von den ganzen Faktoren ab. Aber für 250 gute JUnit tests sind 20 viel viel viel zu wenig (höchstens du hast vor getter und setter zu testen....)

 

[fastjack]

"simple" JUnit-Tests.

Hätte dein Chef mal vorher nachgedacht, müßtet ihr jetzt nicht nachtesten. Nachtesten dauert in der Regel immer länger, weil man immer mehr Bugs findet.
Der normale Weg bei der Entwicklung ist eigentlich:

1. Rümpfe für Methoden schreiben
2. Tests schreiben, die diese Rümpfe nutzen
3. Die Methoden gegen diese Tests implementieren

Ich würde dir empfehlen, einfach Tests für die hoffentlich vorhandenen Spezifikationen der Methoden zu schreiben. Du sollst ja nur die Tests realisieren und nicht dafür sorgen, das der Unterbau bugfrei ist, das können dann die anderen machen

 

[maki]

IMHO: Es gibt keine "simplen" Unittests

Unittests sind auch Javacode.
Die Vorgaben aus der Literatur sind eindeutig: Für "richtig" geschriebenen Produktivcode sollte man nochmals 10-15% der Zeit für Unittests einrechnen.

Das setzt aber einiges voraus, zB. muss die Infrastruktur (Frameworks, Utils/Superklassen) fürs das testen schon bestehen, das schreiben dieser ist nciht in die 10-15% eingerechnet, und der zu testende Code muss wirklich einfach zu testen sein, d.h. die Struktur des Prod. Codes muss "passen".
Mit TDD ist das kein Problem, aber dass ist ja hier offensichtlich nicht der Fall.

Ein sehr gutes Buch zu diesem Thema ist imho "XUnit Test Patterns - Refactoring Testcode".

Nachtrag:
Was ist denn genau mit "TestCase" gemeint?
Zur Laufzeit ist jede Testmethode ein Testcase, zur Programmierzeit meint man aber meist die Klasse(die zur Laufzeit zur Suite wird) die Testmethoden enthält, die "Dualität des TestCases" eben

 

[Verjigorm]

Hätte dein Chef mal vorher nachgedacht, müßtet ihr jetzt nicht nachtesten. Nachtesten dauert in der Regel immer länger, weil man immer mehr Bugs findet.
Der normale Weg bei der Entwicklung ist eigentlich:

Das Produkt ist, wie immer, schon älter und wird jetzt erweitert.
Um eine Aussage über die anstehenden Umbaumaßnahmen zu haben, sollen die Tests diesmal VOR dem Umbau implementiert werden

Ich nehm mal die Zahlen von maki (nochmals 10-15% der Entwicklungszeit) als groben Richtwert.
Kenne mich leider wenig mit guter Literatur aus, in denen sowas behandelt wird :rtfm:

mfg Verjigorm

 

[maki]

...
Ich nehm mal die Zahlen von maki (nochmals 10-15% der Entwicklungszeit) als groben Richtwert.
...

Da wäre ich sehr vorsichtig, die Literatur geht von einer perfekten Welt/perfektem Code mit pefektem Design aus.
Bei "normalen" Code kann das Verhältnis schnell 1:1 betragen oder noch schlechter, Integraitonstests sind auch um einiges aufwändiger als isolierte Unittests.
Der Begriff "untestable Code" kommt nicht von ungefähr

 

[kama]

Hallo,

Um eine Aussage über die anstehenden Umbaumaßnahmen zu haben, sollen die Tests diesmal VOR dem Umbau implementiert werden

Meinem Verständis machen die Unit Tests Umbaumaßnahmen überhaupt erst möglich, da ja sonst keine Grundlage vorhanden ist die Funktionalität zu prüfen. Sprich vorher und nach den Umbaumaßnahmen...Wie würde denn OHNE die Unit Tests die Funktionalität geprüft (Durch Clicken ?? dauert mit Sicherheit länger und ist nicht reproduzierbar...)...dabei finde ich dann dass 2 Wochen (250 Unit Test * 20 Minuten) echt gut Investierter Aufwand wären...

Da merkt man, dass da jemand nicht gut genug über Unit Tests und den weiteren Fortschritt des Projektes nachgedacht hat...

Gruß
Karl Heinz Marbaise

 

[bygones]

oh ich seh gerade es war ja "20min pro Test" und nicht für alle *lol*

 

[fastjack]

Ist wahrscheinlich ein Projekt aus älteren Tagen... Ich war auch schon öfters beim Nachtesten, auch von Sachen, die ich selbst vor Zeiten verbrochen hatte. Mit den ganzen Sachen, die Du umsetzen sollst, bist du Vollzeit locker einen Monat beschäftigt. Wem das zu lange dauert, dem kannst Du einfach folgendes sagen (Spruch merken ): Wenn Du das schneller schaffst als ich, kannst Du es ja machen!

 

[bygones]

wenns ernsthaft wird ist folgende lektüre sehr hilfreich: Amazon.com: Working Effectively with Legacy Code (0076092025986): Michael Feathers: Books