Verwendung von TDD in der Praxis

4 Kommentare

Wie konsequent wird TDD eigentlich in der täglichen Praxis eingesetzt? Wie konsequent sollte es eingesetzt werden?
Um das herauszufinden, habe ich eine kleine Umfrage gestartet, deren Ergebnisse ich demnächst an dieser Stelle auch veröffentlichen werde. Ich bitte um Rege Teilnahme – hier darf nur weiterlesen, wer mitgemacht hat (das dauert nur ca. 2 Minuten) 😉

Umfrage zum Thema „TDD in der Praxis“

Update: Die Ergebnisse der Umfrage sind da.

Meine aktuelle These lautet, dass TDD zwar als hilfreich empfunden wird, entweder aus eigener Erfahrung oder als Erwartungshaltung gegenüber TDD, aber dennoch nicht konsequent in den Projekten eingesetzt wird. Ein Grund dafür ist mit Sicherheit auch ein Mangel an entsprechender Kompetenz.

Eine Möglichkeiten die eigenen Kompetenzen in Sachen TDD weiter aufzubauen sind Katas: Ein Begriff aus dem Karate – es geht nicht darum etwas möglichst schnell zu erledigen, sondern eine Aufgabe möglichst gut zu erledigen. Aufgabenstellungen finden sich im Netz zu Hauf:

  • codingkata.org: Die Liste ist unterteit in verschiedene Schwierigkeitsgerade und bieten sogar Maven 2 archetypes um das Projekt lokal schnell aufzusetzen
  • codekata: Hat die ganze Kata-Geschichte losgetreten
  • codingdojo: Noch mehr Aufgaben zum Üben

Wer sich von anderen inspirieren lassen möchte, findet auch viele Katacasts, wo man den Cracks bei der Lösung zusehen kann. Hier sind beispielhaft zwei Videos von Katas zu unterschiedlichen Aufgabenstellungen.

Übrigens: Wer auf den Geschmack gekommen ist und TDD besser erlernen möchte: Vom 15. bis 17. Juni findet bei codecentric ein TDD-Camp statt! Mehr infos auf: http://www.meettheexperts.de/

Prime Factors Kata in Ruby

String Calculator Kata in Groovy

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

  • raveman

    21. Mai 2010 von raveman

    I just write some functionally using TDD and it was faster than without tests, but it was because i used integration test. I think the more complex thing you implement the harder is to do it using TDD.

    I also did some big functionally using BDD(after code was written) and when i needed to change it I had problem with changing tests. I ended up deleting the tests, because it was too much work to change it. I believe more in Unit Testing than in BDD. However maybe I was testing too much(I tested the whole app using one BDD Test).

  • Andreas Ebbert-Karroum

    Hi raveman,

    that’s a good point you are raising. Of course, if you just have one BDD test for your whole application, you have to adapt that test every time you change the application. Not very desireable. The way BDDs should work is that you express the business rules in a stable, but executable specification. That should not be a test script, which is brittle and probably breaks as soon as you change your implementation. It rather should be a description of the rules. These executable specifications should really only change, when the rules they test are changing.

    The binding of the executable specification to the application, i.e. how the rules are verified, and how the context in which these rules apply is setup, is changing more often, as you work on the code. On the other hand, the keywords or methods for verification and setup can be reused often in the executable specs, so also there the overhead shouldn’t be too big. I should probably blog about that 🙂 Maybe on Tuesday.

    Thanks for your comments, and good that you had good experience with TDD. Regarding the use of integration tests, you might want to watch a presentation of J. B. Rainsberger: „Integration Tests are a Scam“ 😉

    Kind Regards,
    Andreas

  • Travis Calder

    I think it’s important to recognize the focus of TDD. Generally TDD involves mocking and other forms of abstraction, otherwise it’s impossible. With mocking and stubbing introduced, guaranteeing behavior is impossible.

    That’s where BDD and narative-style tests come in, and they are extremely valuable.

    But at the code level, writing code with TDD has a completely different effect. It acts as living documentation of the code that „cannot“ be stale. It allows you to identify, when you refactor or add functionality, what pre-existing assumptions you may have broken so that you can anticipate otherwise-unexpected behaviours.

    Overall I’ve experienced both faster and slower development with TDD. Sometimes a feature is so simple that the TDD is „extra weight“, and sometimes TDD helps me to clarify what I want before I write it. In both cases, though, I find that the long-term maintenance and change costs of the code I’ve test-driven are substantially lower than the „legacy“ code I have to interact with.

    Don’t believe me? Just think about every time, working with untested code, you had to hesitate before making a change because you weren’t sure if it would break things. I work with legacy code every day, that cost becomes large very quickly.

  • raveman

    22. Mai 2010 von raveman

    Thanks for the reponse and insides. I will watch that presentation, however I truly believe that only live(using real servers) integration tests matters.

    For example I had written LDAP library and integration tests that are using real ldap server(I was trying to mocked it, but it was really hard). However when I run my tests Im 100% sure that lib works with chosen ldap server. It has stopped working once, because new version secretly stopped supporting something in ldap language that i had used. Now im happy that i did not mock that server.

    The biggest problem with testing in web is that you are never sure if the code really works. So after writting tests and code you should start server, deploy the app and test it manually(however I do know people that dont do that and just commit the code, i dont have that much self-confidence). its not possible to check if AJAX reRendered the right part of page with right values(and only that matters, it doesnt matter how well code is written if it doesnt work). only live html(selenium, htmlunit, etc.) integration tests on not mocked server can find that error. They dont sound as cool as mocking server, but they give you 100% certainty that code works(that do sound cool).

Kommentieren

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