Yet another example of TDD’s Brilliance.

I woke up this morning and checked my phone, 7 Tests failed.

My initial reaction was anger,  wondering which poor developer I would smack for this change (Luckily the developer was located in poland so smacking is out of the question).
However, as I pulled up my teamcity page, located the exact build and exact line of code that caused these tests to fail, and fixed the bug almost immediately, I began to reflect on what could have occurred had we not had CI or Tests written in this case.

Flash forward, 6months from now.
Client uses the system and calls our support line to say its ‘broken’. They repeat what they did and the task is assigned to me to fix this problem. The support person immediately blames me for this problem.
I pull up the old code from this project, as i’m working on a new project now. I hesitantly attempt to reproduce this problem, breakpointing away until I can find the exact cause of the bug.While pulling this up, my manager asks me how long it will take for me to fix – hinting a bit of anger that I caused this whole mess in the first place. I reply like I do with all bugs – It depends how long it takes me to find it.

This scenario is wrong for so many reasons – and I cannot see why anyone would not want to catch a bug as soon as possible. It takes a lot longer for a developer to catch a bug that is not fresh in their mind, let alone the possibility that end users will have to suffer in this scenario. When we first started the entire re-writing of this project and porting to ruby, to use a BDD/TDD Approach to development, management initially thought I was mad – but when situations occur like this, that could have taken days to fix something so simple – is when it just makes plain sense.

Like:
  • Digg
  • Facebook
  • Google Bookmarks
  • email
  • LinkedIn
  • Twitter
  • MySpace

Leave a Reply