Unit-Tests

[dedlfix]

Tach!

Als Nächstes sollte es dem Test möglichst einfach sein, Erfolg/Misserfolg einer bestimmten Funktionalität feststellen zu können. D.h., dass ein Testergebnis maschinell verwertbar sein sollte.

Ach! Genauso geht man ja test-driven vor. Die Frage war nicht, was TDD ist. Diese Grundfunktionalität beinhalten die TDD-Frameworks.

PS: Meine Units sind Interfaces und Methoden einer Factory, jeweils in einer dedizierten Datei. Da habe ich die Möglichkeit, den Code für einen Test in derselben Datei zu notieren, das ermöglicht Tests bereits während des Entwickeln. So sind auch spätere Erweiterungen schnell getestet, weil der Test sozusagen eingebaut ist. Auf diese Art und Weise sind auch Fehler sehr schnell eingegrenzt.

Selbst wenn man den Test-Code nicht mit dem Produktivcode vermischt, hat man die von dir erwähnten Möglichkeiten. Ob Fehler schnell eingrenzbar sind, hängt nicht vom Test ab, sondern vom Fehler selbst. Wenn TDD eine Hilfe ist, dann spielt es keine Rolle, wo sich dessen Code befindet. Und vor allem hat man bei einer Separierung den Test-Code und dessen Kompilat nicht unnötig in der fertigen Anwendung.

dedlfix.