Ästhetik und Klarheit von Code

[Der Martin]

Hallo,

Natürlich bleiben die Schritte so wie sie sind damit man jeder zeit seine Unittests (oder was man auch immer für ein Testframework benutzt) duchlaufen lassen kann.
Nö. Das mach ich doch nicht immer wieder und wieder, sondern nur während der Entwicklung eines Moduls oder einer Funktion. Irgendwann gilt das Ding als hinreichend getestet und "okay" innerhalb der Spezifikationen.
Dann hast du entweder noch nicht an wirklich großen und komplexen Projekten gearbeitet oder bist ein Genie und Supercoder.

vielleicht von allem etwas. ;-)
Nein, im Ernst: Mag sein, dass ich wirklich noch nicht an "großen und komplexen Projekten" nach deinem Maßstab gearbeitet habe. Aber selbst wenn: Jedes Projekt, und sei es noch so umfangreich, lässt sich in Teilprobleme (Module) mit überschaubarer Komplexität zerlegen. Das Wichtigste dabei ist, dass die Schnittstellen dieser Teilprobleme eindeutig definiert sind.

Schreibt man einzelne Funktionen, mag das ja noch gut gehen.

Genau, jede wird zunächst isoliert für sich getestet: Liefert sie für alle erlaubten Argumente das gewünschte Ergebnis? Wenn das einmal sichergestellt ist, kann man sie mit anderen, ebenso getesteten Funktionen zu einer größeren Einheit kombinieren. Theoretisch müsste diese zusammengesetzte Einheit auch einwandfrei funktionieren, wenn alle Schnittstellen korrekt eingehalten werden. Da aber, wie du schon andeutest, oft der Teufel im Detail steckt, wird diese Ebene natürlich auch wieder getestet - aber dabei betrachte ich nur noch die Schnittstellen dieses Moduls nach außen. Erst wenn ich da feststelle, dass etwas nicht stimmt, muss ich wieder ins Eingamachte, und muss jede interne Schnittstelle erneut untersuchen, bis ich die Funktion(en) gefunden habe, wo der Fehler auftritt.

Erweist sich aber das komplette Modul als fehlerfrei im Rahmen der Spezifikation, dann betrachte ich auch die Funktionen, aus denen es aufgebaut ist, als fehlerfrei unter den gleichen Bedingungen. Ich kann sie also fürs nächste Projekt gleich wieder einsetzen und brauche dort nicht wieder auf dem untersten Level zu testen.

Wenn in einem Projekt aber viele viele Komponenten zusammenspielen, von denen du vielleicht 10% kennst, ...

... dann muss ich wohl den Aufwand treiben, diese Komponenten als "Black Box" ausführlich zu testen. Wünschenswert wäre dabei Zugang zum Quellcode; den hat man aber leider nicht immer. Diese Unwägbarkeiten bei der Verwendung von unbekanntem Code sind aber auch *ein* Grund, warum ich von größeren Frameworks normalerweise Abstand halte. Stattdessen implementiere ich lieber den kleinen Bruchteil selbst, den ich davon nutzen würde. Dann kenne ich meinen Code wenigstens genau und weiß, was er kann oder was er nicht kann. Erfahrungsgemäß ist dieses Vorgehen meist schneller, als sich erst in fremde Frameworks (wie etwa Microsofts .NET) einzuarbeiten.

Oder ich lehne so ein Projekt ab, dessen Umfang oder Komplexität ich nicht überblicken kann.

dann ist es unumgänglich immer wieder Unittests zu nutzen.

Ja. Aber nur noch für die Units/Module, die für sich noch nicht getestet sind bzw. modifiziert oder um etwas Neues ergänzt wurden.

So long,
 Martin