LessCode

Der LessCoder macht es sich von Natur aus einfach und möchte seine Arbeit mit möglichst wenig Code zu Ende bringen. Deshalb schreibt er keine Tests? Falsch! Keine automatisierte Tests zu schreiben ist wie „Keine Zeit zum Säge schärfen, weil doch der Baum gefällt werden muss.“
Aber für den LessCoder ist echtes Test-Driven-Development meist zu viel des Guten. Denn oft „lebt“ frisch geschriebener Code noch eine Weile, bis er sich gut in den Rest des Systems einpasst. Somit tut er besser daran, dem Code etwas Zeit zu geben, sich zu bewähren.
Allerdings sollte er nicht lange warten, ihn durch einen automatisierten Test zu prüfen, denn gerade in dynamischen Sprachen ist es wichtig, aufgrund der fehlenden Typsicherheit mit hohen Testabdeckungen zu arbeiten.
Ganz unabhängig davon gibt es jedoch genügend andere Gründe für eine hohe Testabdeckung, so dass dass die korrekte Typisierung praktisch ohne weitere Aufwendungen ebenfalls mitgetestet wird. Generell lässt sich feststellen, dass dies ein zentraler Punkt ist, warum man mit dynamischen Sprachen so produktiv ist: fehlende Typsicherheit ist nur scheinbar ein Nachteil, die Vorteile durch die Dynamik jedoch immens. Siehe auch den Artikel „Statische vs. Dynamische Typisierung: Overengineering im Kleinen?„