Katas for Practicing Refactoring

Problem

I've tried to do the various TDD katas found laying around on the web (not dissimilar to those found here: http://codekata.pragprog.com/) and found I have a couple issues with most of them. First it has to do with what I perceive a kata to be.

A kata is a choreographed set of movements that are practiced ad-tedium so that they come almost instinctively, one after another. They are very narrow and focused. There is no real problem solving to be found in them.

In completing some of the various katas I've found on the net, I've noticed they are more complex than I'd like, but also, in the end, I don't really know that I've done it right. It's extremely easy for me to get off track. I also never know why I'm doing it. What am I learning? Am I learning?

It's important to note that I'm not saying the TDD katas out there are broken, if they work for you then I don't recommend you stop them although you may still want to give these a try. I'm really just saying that they are broken to me.

Solution

In response to my experiences I came up with the idea of practicing kata forms based on Martin Fowler's book, Refactoring. Almost all of the refactorings in this book are extremely simple and the kata itself implies the "solution" you should arrive at at the end. We do refactorings numerous times daily. A lot of times it's with the help of tools, but there are plenty the tools don't cover. Simultaneously, there are times when your favorite tool is broken (COUGH Resharper 5 Beta COUGH) and you may need to whip one out by hand. Also, there is no need to ponder how to model the domain of the kata. The sample has been TDD'd and all that's left is to refactor the tests and the sample code together into the direction described by Fowler's book. I have decided to keep my samples as close to Fowler's as possible (sometimes steering a little away to maintain my personal coding standards).

That gives us a bonus for free. The refactoring katas also serve as an excellent introduction into what makes TDD addicting, the safety net. When the kata is being refactored, the tests may require refactoring but they shouldn't require massive changes. Everything a practicer might do, should already be covered. This means that if they make a misstep, the tests will usually catch them and guide them back onto the correct path. 

Follow Along

I recommend using Refactoring as a guide to follow along with the refactorings and practicing them until they are a muscle reflex. This is the book to buy in case you're too lazy to Google it: http://rcm.amazon.com/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=justibozon-20&o=1&p=8&l=as1&m=amazon&f=ifr&md=10FE9736YVPPT7A0FBG2&asins=0201485672

Contribute!

I have completed one refactoring and have half of another larger one posted to my GitHub account.There are a lot of refactorings to cover and I could really use some help. I've done the hard part and gotten the project started and added a couple of my favorite refactorings. If you like this whole concept do the same. :)

Where are they Hosted?