Ästhetik und Klarheit von Code

[Christian Seiler]

Hallo Christian,

Dem Rest Deines Postings kann ich uneingeschraenkt zustimmen, aber zu folgemdem nur kurz:

• Die Entwicklung sollte „test driven“ sein: zuerst schreibt man den Test-Fall, dann den Code, aus mehreren Gründen: es hilft einem sich über die Schnittstellen und die Verhaltensweisen klarzuwerden, es verhindert „whitebox testing“ (testen von nur den Positiv-Fällen) und, bei Änderungen bestehender Module, es ist sichergestellt, dass ohne die Änderung der Testfall fehlschlägt.

"Test driven developement" hat auch seine Nachteile, naemlich dass man sich sehr leicht verrennt, alle moeglichen Tests zu schreiben, bis man dann beim Coden merkt, dass das Interface, was man sich so definiert hat, in dieser Form nicht sinnvoll ist. Das muss man in meinen Augen gegen die Vorteile abwaegen, die Du geschildert hast, ich wuerde den Punkt, den Du machst, daher eher so formulieren: Man sollte sich ueber die Methode "test-driven developement" im Klaren sein und deren Vor- und Nachteile fuer jedes Projekt abwaegen und dann entscheiden was man genau macht.

Das aendert natuerlich nichts daran, was Du sonst gesagt hast, d.h. wie Unittests aufgebaut sein sollten und die Tatsasche, dass man diese bei jedem Projekt einsetzen sollte. (Ausnahmen bestaetigen die Regel.)

Viele Gruesse,
Christian