Usage of TDD in practice

How much is TDD used in daily business? How much should it be used?
To find that out, I started a little survey. The results will be made public on this blog soon. I’d love to get as much participation as possible, of course :) So please continue reading only after answering a few questions (should only take two minutes).

Survey regarding “TDD in practice”

Update: The survey results are available.

My current take is, that TDD is expected to be helpful, either by own experience or as an expectation towards TDD, but still its not generally applied in projects. One reason why this is so, might be a lack of competence!

A possibility to build up or extend your TDD competence are katas: a karate term saying that it’s not about doing something especially fast, but especially well. And it needs training to do so. Examples and tasks for katas can be found in the net:

  • A list that group the katas by difficulty. They even have maven archetypes available for most languages, so that you can setup your project quickly.
  • codekata: Kicked off the whole kata story
  • codingdojo: Even more exercises

Those who want to get inspired by others, find a lot of katacasts, where you can watch the experts solving those problems. Here are two casts from different problems in different programming languages.

By the way: If you like to learn more and understand TDD better: We will host a TDD-Camp from June 15. – 17.. Check it out:

Prime Factors Kata in Ruby

String Calculator Kata in Groovy

  • Facebook
  • Delicious
  • Digg
  • StumbleUpon
  • Reddit
  • Blogger
  • LinkedIn
Andreas Ebbert-Karroum

4 Responses to Usage of TDD in practice

  1. raveman says:

    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).

  2. 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,

  3. 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.

  4. raveman says:

    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).

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>