Prime guidelines for Test Driving

• Do. Not. Skip. Refactoring.
  
• Get to green fast.
• Slow down after a mistake.

Let’s go through these guidelines one by one, examining what makes them so
important that they made it to our short list.

Do. Not. Skip. Refactoring.

If you haven’t yet considered tattooing the word refactor on the back of both your hands, now would be a good time to do that. And I’m only half joking. The single biggest problem I’ve witnessed after watching dozens of teams take their first steps in test-driven development is insufficient refactoring.

Not refactoring mercilessly and leaving duplication in the code base is about
the closest thing to attaching a time bomb to your chair. Unfortunately, we are
good at remembering the “test” and “code” steps of the TDD cycle and extremely proficient at neglecting a code smell that screams for the missing step.

Thus, I urge you to pay attention to not skipping refactoring. If you have some-
one to pair with, do so. Crosscheck with your programming buddy to spot any
duplication you may have missed. Bring Fowler’s Refactoring book with you to the toilet. Learn to use your IDE’s automated refactorings. It’s good for you, the doctor said so!

I apologize if I’m being too patronizing, but following the TDD cycle all the
way is important. Now that we’ve got that in check, there are two more guidelines for us to go through. The first of them relates to the code step of the TDD cycle get to green fast. Let’s talk about that.

Get to green fast

As we test-drive, we’re basically aiming for the simplest design we can think of for the problem at hand. We don’t, however, go for the simplest design right off the bat in the code step. Instead, we should strive to get back to green fast. The code step is where we get to that green bar with as few edits as possible. The refactoring step is where we perfect our design.
You might want to read the previous paragraph out loud. Don’t worry about
others looking at you like you’re a freak. You’re just pointing out facts.
Speaking of facts, it’s more than likely that you will make one or two mistakes
in your career even after adopting TDD. Our third guideline tells us to slow down once the proverbial smelly substance hits the fan.

Slow down after a mistake

It is common for developers practicing TDD to start taking slightly bigger and bigger steps as time goes by. At some point, however, we’ll take too big a bite off our test list and end up reverting our changes. At these points, we should realize that the steps we’re taking are too big compared to our ability to understand the needed changes to our implementation. We need to realize that we must tighten our play. Small steps. Merciless refactoring. It’s that simple. Walking to the water cooler might not be a bad idea either.

These guidelines are certainly not a complete reference to successful test-
driving. Practices and guidelines don’t create success. People do. Having said
that, I hope they will help you find your way to working more productively and
to avoiding some of the pitfalls I’ve seen many people stumble into as beginning TDD’ers.

read more : http://www.manning.com/koskela/