Ergebnisse der Umfrage zum Einsatz von TDD

3 Kommentare

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?

Andreas Ebbert-Karroum

Andreas Ebbert-Karroum ist Agile Principal Consultant bei codecentric und Product Owner von CenterDevice.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Giorgio Sironi

    I actually did a presentation in a conference which main points was: if it’s testable, it’s maintainable. Testing a component means bring it in an unfamiliar environment (the test case), so decoupling is strongly influenced by testability.

  • ferrisoxide

    TDD is a design practice. As one of your respondents has said, problems stem from treating your tests as second class citizens and not allowing the design of your code become more refined through refactoring.

    TDD and maintainable code go hand in hand. TDD (usually) leads to simpler and explicit designs with less code to maintain.

    I think the statement you put forward is interesting, but it hints at one of the popular misconceptions about TDD – i.e. that it’s about *testing* when in fact it’s really about *design*.

    I’ve just had a wonderful experience teaching some younger developers how to refactor their code using TDD. The joy on their faces when it all worked was so evident it made me feel awesome. So TDD is also about programmer happiness – I doubt there’s a metric that can measure that.

  • Uwe Friedrichsen

    A remark from an architect’s point of view (you know: one of those odd guys from the 90s that is no longer of any use in the time of agile … 😉 ):

    I think basically TDD is a very useful technique that helps a lot to improve design because it urges you to think about *what* you want to do (contract) before *how* you want to do it (implementation).

    But as with all good (and bad) techniques it has a tradeoff. TDD contains the inherent risk that you might start to do design just for the sake of testability, i.e. that you might start to make design decisions that do no longer support the goal of the application but just testability. A good indicator is that you start to introduce code for the sake of testability that your application does not neeed to fulfil the requirements (instead of looking for the right interface „cut“ through your existing code that provides the required testability).

    But that should be enough about the risk. TDD is very useful and it should be used definitely! … just make sure that it does not become an end in itself … but that applies to all good techniques … 😉

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.