Few weeks after the great AgileByExample conference, I had the privilege to be an organizer of, I have few thoughts about TDD I would like to share.

If you are an experienced TDD hacker, then probably this would be no value for you, but If you are a beginner then you might enjoy it 😉

The conference was really an eye opener for me. Basically I had an idea what TDD could be. I went to many presentations in the past that were trying to convince the audience, how great and awesome TDD is, and how it can cure cancer, but I think the presenters were very often missing the point there.

The point that I think I feel much better now, after taking part in a great Coding Dojo, that was lead by two great agile masters – Alexandru Bolboacă and Thomas Sundberg.

So the thing is – I always thought about TDD to be the Test Driven Development. But that is not all. That always implied for me, that I need to design first, and then do the TDD. And that really did not make much sense, cause If I knew that I need to create class Dog class Cat class DogDecorator class ViewPetHolder etc. – why would I start with test that checks that method which returns “Dog” really returns “Dog” 😉

But if you think Test Driven Design, which I think is more accurate, you will find out, that you shouldn’t be thinking about how to achieve the goal – the actual solution will emerge from the tests.

I have seen it just yesterday when I remote paired with Alex, to practice a bit and see with my own eyes, that remote pair programming is possible.

Two things came out of it – Alex showed me how refactoring, like changing the names of variables to something more descriptive naturally creates the classes for you.

And that remote pair programming is as possible as one-room-pair-programming. We had absolutely no problems in doing that – one thing you need to do is that everyone writes on his own laptop, while the other is looking at it (try TeamViewer for example). Once one is done with his stuff the other needs to get his changes, for which any version control would be sufficient. We were using public github account.

I might not be 100% converted, but for some problems I can see a good use of this approach.

Oh and the shared code knowledge, and double the brain you get for free 😉

TDD – Test Driven D???

3 thoughts on “TDD – Test Driven D???

  • September 27, 2011 at 10:23 am
    Permalink

    Hi Szimano,

    My have similar feelings after AgileByExample. I did some research how similar approach can be applied in RoR. The only thing missing for me to be 100% converted is to solve following problem: not everything is that easily refactorable as java code. Think about htmls, javascript, database structure. I’d like to see how one could work with those in strict TDD/BDD-design-will-emerge style.

    Cheers!
    Marek

    Reply
    • September 27, 2011 at 10:37 am
      Permalink

      Yeah, had a similar discussion with Alex yesterday on how you can do that with user interface.

      Basically the idea is that you have as thin UI layer as possible, and with TDD you will get up to your controllers/model beans etc – the htmls, you write in the end, and those cannot be easily refactored or done in TDD/BDD manner

      Reply
  • September 27, 2011 at 11:14 am
    Permalink

    And I have always thought that TDD means Tomek Dziurko Developing so I was putting it in my CV with value equals to the length of my Developer career 😉

    Reply

Leave a Reply

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