Writing Code that doesn't suck

written by Martin Häcker on

Und noch mal von den Confreaks.

Ausgezeichneter Vortrag von Yehuda Katz darüber was er für gute Tests hält und was nicht. Sein Argument: Am Ende will man Regression-Tests haben, da nur die wirklich nützlich sind beim Refactorieren. Nur die sind nützlich, weil dass die Tests sind die man behalten kann während man den Code neu faktoriert.

Damit das geht muss der Code aber schon eine gute Faktorierung haben die man (ausschließlich?) über öffentliche Interfaces testen kann.

Wohlgemerkt in dem Talk geht es nicht darum ob TDD gut oder schlecht ist - der Zweck ist einfach ein anderer. Ihm geht es um API-Stabilität und die Frage wie man Interfaces (nicht Implementierungen) über eine lange Entwicklung stabil hält.

Spannend. Mir ist dabei eingefallen dass ich damals im ersten Buch über Test Driven Development einen Absatz gelesen habe in dem Stand dass man zuerst seine Tests schreiben soll um dann an diesen seinen Code zu schreiben und zu refaktorisieren. Und dass man danach den Code als Tests für die Tests verwenden kann um wiederum diese zu refaktorisieren.

Gaudio. Ob das schon das ist was Yehuda meint? Ich vermute noch nicht ganz - aber es hört sich für mich nach etwas an was ich direkt tun kann - ich kann meine Tests betrachten und mir anschauen ob sie tatsächlich das testen was mich interessiert (das interface) und wenn dem nicht so ist, dann kann ich mir das Interface betrachten und die Tests tatsächlich refaktorieren.

Yay, mehr Arbeit. :)