Letzte Woche hatte ich zu einer kleinen Umfrage aufgerufen, deren Ergebnisse ich nun hier präsentieren möchte.
Insgesamt haben 17 Teilnehmer an der kleinen Umfrage teilgenommen. Hier lassen sich also bei weitem keine statistisch belastbaren Aussagen treffen, sondern allenfallt Tendenzen aufzeigen und Denkanstöße geben.
Do you use TDD in your current project?
Mehr als drei Viertel der Befragten antworteten mit „Ja“. Die Kommentare in dem vorherigen Blogpost lassen aber darauf schließen, dass TDD nicht für alle das gleiche heißt. Hier wäre bestimmt noch ein weiterer Blogeintrag angebracht.
Von denen, die angegeben haben TDD einzusetzen, war die Einsatzdauer gestreut. Drei arbeiten erst seit einem Jahr mit TDD, 4 schon seit über drei Jahren. Interessant sind die Gründe, warum kein TDD eingesetzt wird oder werden kann. Hier ein paar Auszüge:
I’m extending others code which would require a complete rewrite to use tests.
Perceived time pressure
Could not convince the managers to adopt TDD and people could not get the concept […]. They felt its an uncalculated risk which can have major repercussions as there are no proven metrics supporting the TDD methodology.
What programming languages do you use in you current project?
Hier gibt es wenig Überraschungen, außer vielleicht der große Ruby-Anteil.
Have you found (if you use TDD) or would you expect TDD to have an impact on
Hier war die Frage welche Konsequenzen der Einsatz von TDD hat. Während der Einfluß von TDD auf die Anzahl der Bugs, Designqualität und auch die Freude an der Arbeit positiv gesehen wird, sind die Einschätzungen bezüglich des Aufwandes geteilt. Die fehlenden Studien zum meßbaren Effekt von TDD wurde ja auch schon von einem Teilnehmer beklagt.
How would you rate TDD compared to other techniques?
Hier sollten die Teilnehmer verschiedene Techniken der Softwareentwicklung priorisieren. Das Diagramm gibt die gemittelte Platzierung und die Varianz der Ergebnisse an. Das Ergebnis ist meiner Meinung nach sehr interessant. Noch vor TDD landet „Clean Code „. Dann kommt TDD, dicht gefolgt von Domain Driven Design. Wer hätte das gedacht?
Im Mittelfeld tun sich die Kontrahenden nicht viel: Pair Programming, ATDD und gute Kommentare und Dokumentation werden im großen und ganzen als gleichwertig angesehen. Die statische Codeanalyse fällt dagegen schon deutlich ab. Klarer Verlierer ist UML. Klar, braucht kein Mensch … oder sind die Tools einfach nur unbeliebt?
What’s your position on the statement, that code that results from TDD is primarily designed for testability, but not necessarily for maintainability.
Zu guter Letzt habe ich noch eine These in den Raum geworfen, welche sehr spannende Kommentare provoziert hat. Wir können die Diskussion gerne in den Kommentaren hier im Blog fortsetzen.
Pro
Die Argumente der „Pro“-Seite lassen sich darauf zusammenziehen, dass TDD alleine nicht ausreicht. Man kann guten und schlechten Code auch mit TDD schreiben. Dabei kommt es hauptsächlich darauf an, die Refactoring-Phase und Designprinzipien wie SOLID, DRY, etc. nicht zu vernachlässigen. Wer aufhört sobald die Tests grün sind, hat nur die halbe Arbeit erledigt. Und auch das ist ein Argument: der Aufwand für die zweite Hälfte (das Refactoring) erscheint einem Teilnehmer unangemessen hoch.
Good test-driven code is both, testable and maintainable. But I can also write bad (maintainable) code in a test-driven way, that’s the problem.
TDD-Code, when written well, aids maintenance. Test-Code, when written bad, hinders maintenance (that’s why test-after-test are generally a bad idea)
TDD paired with a good understanding of refactoring, the SOLID principles, YAGNI, DRY etc results in some of the most beautiful, reuseable and highly maintainable code a developer can write.
I agree with the statement 100%. I often find that developers are writing code specifically to make it testable, which leads to poor design, poor maintainability. Also, writing tests consumes so much additional development time that very little effort is spent on the refactoring steps, which again leads to poor design. Personally I would be interested to know what sort of impact code coverage targets have on the TDD process. Are developers simply writing tests for coverage or are they actually creating meaningful tests. We have a 90% target at my current shop and I have found that there is a ton of copy/paste coding going on here simply because the developers know there is already test code written that will cover the code.
Kontra
true but maintainability is a side effect.
When maintaining a system written using TDD, the tests act as active living documentation on what important features the code actually has, as opposed to side-effects that aren’t required. Without TDD you have to rely on comments and documentation, which often become stale and outdated. In fact, that is why I ranked clean code lower than TDD, DDD, and Pair Programming. In my experience, these three practices heavily drive Clean Code.
If, for example, you refactor a system that was not written with TDD that is not fully tested, how do you know if you broke an existing assumption?
If, instead, you refactor a system that was written with TDD, you can determine what assumptions you may have broken, and choose to restore them or amend them. Often tests will fail as a part of refactoring, but knowing why the tests failed allows you to anticipate otherwise-unexpected system behaviour.
Don’t agree. TDD often lead to a very clean and maintainable code.
Testable code has usually fewer and looser dependencies, if done in a top-down manner it’s also simpler. All of these directly contribute to maintainability. Some people treat test code as „second class“ code, which does not need to be DRY or refactored. I think it’s from such behavior that the misconceptions about TDD stem.
Wie ist Ihre Meinung zu der These, dass TDD in erster Linie testbaren Code erzeugt, der nicht notwendigerweise wartbarer ist als „normaler“ Code?
War dieser Beitrag hilfreich?
Weitere Beiträge
von Andreas Ebbert-Karroum
18.11.2020 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Andreas Ebbert-Karroum
Agile Principal Consultant
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.