Skip to content
April 12, 2015 / Samer Baydoun

Baby Step TDD

At one of the Softwareskammer’s sessions in Munich, we were introduced to a new practice of Test Driven Development called Baby Steps.

The Baby Step TDD came up as a solution for the problem of TDD when sometimes you write a test which forces you to implement too many changes in one step to make the test pass.

As known, the main cycle in the TDD is described as follow:

  1. Start
  2. Write a failing test
  3. Write code to make test pass (then goto 2, or if can’t think of more tests, refactor)
  4. Stop

With the Baby Step we had to do the same cycle but with an extra constraint that it must be done in 2 minutes. So at the end of each cycle the test must be “green” (test passes).

Now, the most painful condition was that if you finish on red you have to roll back your changes to the last “green” state.

We had to write Java code printing diamond, as described in Seb Rose’s post, and use git for committing the “green” code at the end of each cycle or rolling back “git reset –hard HEAD” when it is “red”.

From my point of view, in spite of the fact that the rolling back after each red cycle drove me crazy, I think the method is good in a way that it forces me to divide the problem to small problems and write more cohesive chunks of code while trying to keep the test passing in 2 minutes.

Putting this practice in production, once understood correctly, will guaranty a better code quality on the long run; however, it may not seem a good idea for some developers, as it presents a relatively slow process.

Advertisements

2 Comments

Leave a Comment
  1. David Völkel (@davidvoelkel) / Apr 14 2015 5:29 pm

    Hi Samer,

    Glad to hear that the approach is valuable to you!

    In my personal experience it’s a very important tool in my daily work not to get lost in the complexities we are facing. Though in reality I use it more pragmatically and more as a goal instead of a hard constraint. So the two minutes in the kata are a means to challenge your comfort zone. It should force you to search for ways how to slice a big change into smaller steps. And of course raise the awareness that it is possible anyway and even becomes quite easy after some practice. So I use the revert back to green only if I see I am on the wrong track and not when my dumb timer is ringing.

    Another soft variable that drives the size of the steps I can handle is the risk associated with my current change. Some structural refactorings my IDE performs for me: OK, I can be a bit lazy and risk bigger steps without a test run or commit in between. Changes in conditionals: no way, I have do work quite disciplined and mitigate the risk by taking really small baby steps.

    Cheers
    David

  2. Samer Baydoun / Apr 14 2015 7:40 pm

    Hi David,
    thanks for the replay. It’s nice to know you are using the Baby Steps in your daily work too.
    Regarding the rolling back after test fail, I was skeptic about how serious could this constraint be taken in the daily life, and now you confirmed my doubt some how.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: