So test-driven development includes "refactor" as its third step. Every time through the cycle, you're supposed to stop and look for opportunities to improve the code. Everybody knows that. (Okay, not everybody.)

But what does that mean? What should you do when you refactor? If you're doing TDD right, you're taking eensy-weensy steps. Half the time, there aren't enough changes to have anything to refactor.

I don't know about you, but I use the opportunity to add a bit of Beauty to my code. Thanks to TDD, my code already has Truth. It works. Now I make sure it isn't just good, it's beautiful. Gorgeous. The best damned code I know how to write.

This usually comes down to the most trivial of changes. Make the names consistent. Group related code together. Delete that blank line. Shift the parenthesis over. Reflect on how people will use it. Does it all make sense? Is there some assertion I can add that will warn people of common mistakes?

It doesn't sound like much, but for me, it's the final touch. I write good code. I take pride in my work. When you look at my code, you can tell.