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. :)