Siehe EntwurfsMuster.
So, nun habe ich noch eine Frage. Gibt es eigentlich ein Pattern, das Unit-Tests unterstützt? Damit meine ich nun keinen Hokus-Pokus, sondern eine Beschränkung bei der Implementierung von Funktionen.
Ich meine, dass es bestimmte Kriterien gibt, wann eine Funktion leicht testbar ist. Wenn diese Kriterien nun durch ein Muster eingehalten würden, müsste es leichter sein Software-Tests durchzuführen.
Mein Code ist nun zwar sauber nach dem MVC-Muster implementiert, aber testbar sind die Klassen & Funktionen trotzdem nur bedingt!
Kann aber auch sein, dass ich deshalb etwas verkorkste Funktionen implementiert habe, weil ich die Tests nicht schon vor der Implementierung geschrieben habe ;-)
Gibt es Rettung? --DanielBrüßler
: Mit ziemlicher Sicherheit ist Deine Vermutung hier zutreffend: wer (Unit-)Tests nach dem Coden implementiert, stößt häufig auf das Problem: "Das kann man ja gar nicht testen...!?" Tatsache ist: man kann so ziemlich alles und jedes testen. Dein Problem nun: wie kannst Du Deinen Code so verändern, dass Du ihn testen kannst, ohne Gefahr zu laufen, daß Deine Funktionen im Nachhinein noch so funktionieren wie vorher? Und vor diesem Problem, refaktoriesieren ohne Tests, versucht Dich jeder TDD-Guru zu warnen, wenn er sagt, Du sollst zuerst testen und dann coden.
: Pattern fürs TDD gibt es. Besonders gut sind sie meiner Meinung nach in TestDrivenDevelopmentByExample von KentBeck beschrieben. Es sind vier Pattern dort beschrieben: Obvious Implementation, Fake it til' make ist, Triangulation, und das letzte fällt mir bestimmt heute abend zu Hause ein (denn da hab ich das Buch) ;-) Es sind aber alles Pattern, die beschreiben, wie man zuerst testet und dann coded.
: Patterns über das Refactorisieren bzw. Testen von LegacyCode? (und das ist, was Du hier hast - jetzt schon!) gibt es von
Wiki:MichaelFeathers im Buch Working Effectivily with Legacy Code (
ISBN 0131177052). Ich hab's nicht gelesen, aber auf der XP2004 einen Vortrag von ihm gehört, in welchem er einen verwurschtelten Code, ungetestet, Stück für Stück mit Unittests abgedeckt hat. Er hat dabei verschiedene Pattern verwendet, die es ihm erlauben, möglichst keine Funktionalität zu ändern.: Als Lösung für Dich, wenn Du vorhast, Deinen Code noch zu unittesten: entweder nochmal neu schreiben, diesmal aber testgetrieben. Sofern Du noch nicht vertraut bist mit TDD ist dies eine gute Übung für Dich, da reinzufinden. Aber schau Dir dabei nicht Deinen bereits geschrieben Code an, denn der bringt Dich nur auf falsche Gedanken! Der andere Weg: Deine Anwendung mit AkzeptanzTests testen, damit die Funkionalität abgesichert ist. Danach Unittests für Units formulieren. Verlangen sie nach Schnittstellen, die Du noch nicht hast, oder aber Teilen vom Code, der momentan nicht oder sehr schlecht zugänglich ist, dann refaktorisiere Deinen Code, so daß Du das Verlangen der Tests befriedigen kannst. Die Akzeptanztests halten Dich fern von größeren Katastrophen, sofern Du sie regelmäßig (nach jedem Refactoring!) anstößt.
: Zum Kriterium, welches garantieren soll, daß Code testbar ist: TestFirst. Je schwieriger es Dir fällt, einen Test zu schreiben (je länger der Test wird), desto eher hast Du schwer testbaren Code vorm geistigen Auge. Einfachheit (Simplicity) Deines Codes ist es, worüber Du Dir dann Gedanken machen solltest.
: Hilft das ein wenig? --BerndSchiffer
Die Kategorisierung ist nur mein Vorschlag. Passt es? --DanielBrüßler
Siehe TestgetriebeneEntwicklung SoftwarePatterns PatternSprache
WardsWiki:DesignPatternsKategoriePattern KategorieDesign KategorieXp KategorieTesten