Skip to content

TDD Zitatsammlung

Jump to bottom
bodote edited this page Sep 12, 2020 · 23 revisions

Table of Contents

Aus Langlebige Softwarearchitekturen

Abschnitt 9.1.1:

"Für Klassen, die in Zyklen sind, existieren in den meisten Systemen keine direkten Unit-Testklassen. Wollte man die Unit Tests program- mieren, müsste man alle im Zyklus verflochtenen Klassen durch einen Mock ersetzen oder Objekte von ihnen erzeugen. Das ist sehr viel Auf- wand, den die meisten Entwicklungsteams und Projektleiter scheuen."

Bodos Kommentar:
Ich hoffe, wir sind uns einig, dass Zyklen, egal ob auf Modul/Package-Ebene oder auf Ebene von Klassen innerhalb eines Packages böse sind. Daher:
Das heißt im Umkehrschluss: wenn ich mit TDD anfange, kann mir das nicht passieren. Im Gegenteil: TDD hindert mich direkt daran, solche Fehler zu machen und zwingt mich, vor schreiben von Classen und Methode mir Gedanken über die Microarchitektur (also die Architektur von Klassen, die zu einem Bounded Context gehören, die zu einem Package gehören oder sonst eng zusammengehören.)

aus Test-Driven Java Development - Second Edition

Kapitel 1 , Abschnitt "Why TDD?":

"It's not an easy thing to master TDD. Even after learning all the theory and going through best practices and anti-patterns, the journey is only just beginning. TDD requires time and a lot of practice. It's a long trip that does not stop with this book. As a matter of fact, it never truly ends. There are always new ways to become more proficient and faster. However, even though the cost is high, the benefits are even higher. People who have spent enough time with TDD claim that there is no other way to develop a software. We are one of them and we're sure that you will be too."

Bodos Kommentar:
den fett gedruckte Satz kann ich aus eigener Erfahrung bestätigen.

Assessing test-driven development at IBM:

"In a software development group of IBM Retail Store Solutions, we built a non-trivial software system based on a stable standard specification using a disciplined, rigorous unit testing and build approach based on the test-driven development (TDD) practice. Using this practice, we reduced our defect rate by about 50 percent compared to a similar system that was built using an ad-hoc unit testing approach. The project completed on time with minimal development productivity impact. Additionally, the suite of automated unit test cases created via TDD is a reusable and extendable asset that will continue to improve quality over the lifetime of the software system. The test suite will be the basis for quality checks and will serve as a quality contract between all members of the team."

Clone this wiki locally