-
Notifications
You must be signed in to change notification settings - Fork 0
TDD Zitatsammlung
"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.)
"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.
"... 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."
- 2,6-4,2 mal mehr Bugs , wenn KEIN TDD verwendet. oder anders gerechnet Bugrate sinkt mit TDD um 62%-77% .
- 15% -35% mehr Zeit für TDD notwendig.
"... Our results indicate that test-first programmers are more likely to write software in more and smaller units that are less complex and more highly tested...."
"Our results suggest that TDD helps in reducing overall development effort and improving developer's productivity whereas the code quality seems to be affected by the actual testing efforts applied during a development-style."
Metastudie: How Effective is Test-Driven Development?
"Is it for everyone?
One basic fact on which almost everyone agrees is that TDD is difficult to learn. It involves a steep learning curve that requires skill, maturity, and time, particularly when developers are entrenched in the code-then-test paradigm. Better tool support for test-case generation and early exposure in the classroom to a test-then-code mentality may encourage TDD adoption."
"Could it be addictive?
Personal communications with TDD developers suggest that it is an addictive practice. It changes the way people think and their approach to coding in a way that is difficult to roll back. Therefore, leaving TDD practices may be as difficult as adopting them."
Fazit: Empfehlung für TDD
"TDD has several purported benefits—only one of which is software defect reduction ... We found that code inspection is more effective than TDD at reducing defects, but that code inspection is also more expensive to implement. We also found some evidence to indicate that TDD may result in an implementation cost savings, ..."
Empirical studies by Madeyski (Madeyski, 2010a) showed that TDD is better in producing loosely coupled software in comparison with traditional test last software development practice.