Ästhetik und Klarheit von Code

[DaBear]

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?

Da fängt es ja schon an. Manchmal ist das "gewünschte Ergebnis" zwar eben dieses, aber trotzdem logisch falsch. Solche logischen Fehler pflanzen sich oft lange lange fort und tauchen plötzlich irgendwo auf und man fragt sich warum. Syntaktische Fehler lassen sich da vergleichsweise schnell beheben.

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

Und jetzt stell dir vor du hast 100 dieser Ebenen. Und nun stell dir vor, es soll sich grundlegend etwas ändern (Kunden...) und du musst die Struktur und die Zusammensetzung/Kombination der Module ändern. Und jetzt stell dir vor, dass du auf externe Module angewiesen bist, vielleicht sogar auf solche, die du nicht einmal per reverse engineerung analysieren kannst.

Und zu guter letzt ist es viel zu aufwendig wirklich jeden Testfall durchzuspielen. Und mit den bisher vorhandenen Testfällen mögen die bisherigen Module korrekt zu sein scheinen, aber im zusammenspiel wird dann plötzlich ein vorher nicht getester Fall relevant.

In der Theorie mag das, was du sagst, funktionieren. Aber die Realität zeigt, dass dies ab einer gewissen Größe zu aufwendig wird und aufgrund unterschiedlicher Informatiker/Programmierer (die alle unterschiedliche Fehler machen) kaum machbar ist.

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.

Und wenn sich diese Komponenten verändern (z.B. SaaS o.ä.)? Dann müsstest du bei jeder Änderung (die du meist nicht mitkriegst) erneut manuell 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.

In einem privaten Projekt geht das wohl. Nicht aber auf geschäftlicher Ebene. Aus vielen Gründen.