{"id":45230,"date":"2025-05-05T13:50:28","date_gmt":"2025-05-05T11:50:28","guid":{"rendered":"https:\/\/www.happycoders.eu\/bad-tests-good-tests\/"},"modified":"2026-04-14T22:40:07","modified_gmt":"2026-04-14T20:40:07","slug":"bad-tests-good-tests","status":"publish","type":"post","link":"https:\/\/www.happycoders.eu\/de\/buecher\/bad-tests-good-tests\/","title":{"rendered":"Bad Tests, Good Tests - Tomek Kaczanowski"},"content":{"rendered":"\n

Bad Tests, Good Tests<\/h1>\n\n\n\n
\n
\n

von Tomek Kaczanowski<\/p>\n \n

Tests und testgetriebene Entwicklung (TDD) sind in den meisten IT-Teams angekommen. Tests sollen das korrekte Verhalten neuer und bestehender Features sicherstellen, dabei Refactorings unbeschadet \u00fcberstehen, als Dokumentation neuen Entwicklern den Einstieg in den Code erleichtern und \u2013 obendrein \u2013 zu sauber(er)em Code f\u00fchren.<\/p>\n

Leider sind viele Tests die Zeit nicht wert, die in ihre Entwicklung investiert wird. Sie sind schlecht les- und wartbar. Und oft m\u00fcssen sie bei Refactorings angepasst werden, da sie nicht das Resultat einer Operation verifizieren, sondern wie<\/em> die Operation ausgef\u00fchrt wurde.<\/p>\n

Bad Tests, Good Tests erkl\u00e4rt anhand zahlreicher Beispiele (etwa die H\u00e4lfte des Buches enth\u00e4lt Code) was schlechte Tests ausmacht \u2013 Beispiele, wie der Autor sie in realen Projekten vorgefunden hat. Jedem Beispiel stellt der Autor dann konkrete Verbesserungsvorschl\u00e4ge gegen\u00fcber.<\/p>\n

Die Bandbreite der M\u00e4ngel reicht von schlechter Lesbarkeit (z. B. lange Setup- oder Assertion-Bl\u00f6cke) und offensichtlichen Fehlern (z. B. vergessene Assertions) \u00fcber l\u00fcckenhafte Tests (die trotz ge\u00e4nderter Funktionalit\u00e4t nicht fehlschlagen) und subtile Fehler (z. B. Exceptions, die an anderen Stellen als erwartet geworfen werden) bis hin zu v\u00f6llig unn\u00fctzen Tests (die z. B. die Test-Library verifizieren anstatt den eigenen Code).<\/p>\n

Das Buch ist au\u00dferordentlich praxisnah und sowohl f\u00fcr Anf\u00e4nger als auch f\u00fcr fortgeschrittene Entwickler geeignet.<\/p>\n

Anf\u00e4nger m\u00fcssen die Fehler nicht wiederholen, die andere vor ihnen gemacht haben. Fortgeschrittene Programmierer werden sicher das eine oder andere Anti-Pattern aus ihrer t\u00e4glichen Arbeit wiedererkennen und k\u00f6nnen ihre Toolbox mit neuen Techniken f\u00fcllen.<\/p>\n

Der Autor schreibt verst\u00e4ndlich und humorvoll. Und er weist ausdr\u00fccklich darauf hin, dass man seine Regeln auch brechen darf, wenn es im Einzelfall der Sache dient.<\/p>\n

Eine klare Empfehlung f\u00fcr jeden Java-Entwickler.<\/p>\n

\ud83c\udfa7 Geeignet als H\u00f6rbuch? Nein, aufgrund zahlreicher Codebeispiele.<\/em><\/p>\n <\/div>\n \n\n \n

\n
\"Bad<\/a><\/figure>\n \n\n \n

Buch bei Amazon kaufen *<\/a><\/p>\n \n\n\n \n

Genres<\/h4>\n \n\n \n

Softwaretests<\/a> Softwareentwicklung<\/a> Programmierung<\/a> Informatik<\/a> <\/p>\n <\/div>\n <\/div>\n\n\n\n

Andere Empfehlungen aus den Genres dieses Buches<\/h2>\n\n\n\n
\n \n
\n
\"Growing<\/a><\/figure>\n \n\n \n

Growing Object-Oriented Software, Guided by Tests<\/a><\/p>\n \n\n \n

Steve Freeman und Nat Pryce<\/p>\n <\/div><\/div>\n \n \n

\n
\"Effektives<\/a><\/figure>\n \n\n \n

Effektives Arbeiten mit Legacy Code. Refactoring und Testen bestehender Software<\/a><\/p>\n \n\n \n

Michael C. Feathers<\/p>\n <\/div><\/div>\n \n \n

\n
\"Clean<\/a><\/figure>\n \n\n \n

Clean Code \u2013 Refactoring, Patterns, Testen und Techniken f\u00fcr sauberen Code<\/a><\/p>\n \n\n \n

Robert C. Martin<\/p>\n <\/div><\/div>\n \n \n

\n
\"Design<\/a><\/figure>\n \n\n \n

Design Patterns: Entwurfsmuster als Elemente wiederverwendbarer objektorientierter Software<\/a><\/p>\n \n\n \n

Erich Gamma, Richard Helm, Ralph E. Johnson, John Vlissides<\/p>\n <\/div><\/div>\n \n \n

\n
\"Refactoring:<\/a><\/figure>\n \n\n \n

Refactoring: Wie Sie das Design bestehender Software verbessern<\/a><\/p>\n \n\n \n

Martin Fowler<\/p>\n <\/div><\/div>\n \n \n

\n
\"Clean<\/a><\/figure>\n \n\n \n

Clean Craftsmanship: Best Practices, Standards und Ethik f\u00fcr die Softwareentwicklung<\/a><\/p>\n \n\n \n

Robert C. Martin<\/p>\n <\/div><\/div>\n \n \n

\n
\"Der<\/a><\/figure>\n \n\n \n

Der pragmatische Programmierer: Ihr Weg zur Meisterschaft<\/a><\/p>\n \n\n \n

Andrew Hunt und David Thomas<\/p>\n <\/div><\/div>\n \n \n

\n
\"Pattern<\/a><\/figure>\n \n\n \n

Pattern Hatching: Design Patterns Applied<\/a><\/p>\n \n\n \n

John Vlissides<\/p>\n <\/div><\/div>\n \n \n

\n
\"Clean<\/a><\/figure>\n \n\n \n

Clean Coder: Verhaltensregeln f\u00fcr professionelle Programmierer<\/a><\/p>\n \n\n \n

Robert C. Martin<\/p>\n <\/div><\/div>\n \n<\/div><\/div>\n\n\n\n

* Hinweis: Wir teilen gerne unsere Lieblingsb\u00fccher mit dir! Als Amazon-Partner verdienen wir eine kleine Provision bei Eink\u00e4ufen, die du \u00fcber unsere Links t\u00e4tigst. Dies hilft uns, weiterhin Inhalte zu erstellen, die dir gefallen.<\/em><\/p>\n