There's more to it than red, green, refactor or, as others have pointed out red, green, refactor, refactor tests. Or as Uncle Bob says podcast-giant-robots-79-uncle-bob... refactor tests, red, green, refactor, refactor tests (did he say before and after in his talk with Ben Ornstein?))
"Why do we separate out the green step from the refactoring step? Why do you make it work, not really worrying about the code quality, and you are then cleaning by refactoring?
...
Kent would say, "when you're adding new functionality to the code, you're thinking in a different mindset than when your refactoring" Refactoring, strictly defined, is changing the way the code is organized, but without actually changing its observable behavior.
...
It's easier to think of only doing one thing at a time.
The other question is, when does real refactoring kick in? Not necessarily after each cycle (you may do none!).
"Duplication Is Better Than The Wrong Abstraction
The next thing we were told to do goes against all intuition.
Write shameless code, full of duplication just to make the tests green."
The other way of thinking about it is that you should switch into a refactoring mode testing-concept-explicitly-switching-to-refactoring where you forget about what you are trying to accomplish with the code and tests and think only about the very practical step-by-step process of refactoring using the techniques at your disposal (the techniques in the refactoring book).
Additionally, some things to consider:
At 20:40, ask yourself additional questions when you hit the factor point in TDD
Is it DRY? Does it have one responsibility? Does everything in it change at the same rate? Does it depend on things that change less often than it does?
When the main cases are done, you try to think of ways to break the existing code.
Good red, green, refactor forces you to "stay on the baby steps path". This can't be overstated. When I first bumped into Martin Fowler's "refactoring" I couldn't believe how little he did at each step. (This also plays into fast testing, since you need to be able to run them all the time)
The idea of the Kata is to do it over and over again. The reason we do this... the red, green, refactor... is so that when my boss comes to me and says "Jim, I need this fixed in a day... can you get this done by this afternoon?" And I don't panic and just start writing random code, because I've got the discipline of practicing the TDD over, and over, and over again, it's actually much faster for me to fall into the good habits that I've developed by practicing the katas then to fall out of them and ignore all the good things that I know about how to develop software. That's the real purpose of the kata.