Refactoring to Anti-Patterns
We all know the idea of refactoring to patterns is good. In fact that's generally how I refactor. I see a code smell (say you have a loop that is doing too many things) and refactor to a pattern like Split Loop in order to fix the smell. How about refactoring to Anti-patterns? Or just plain detecting Anti-patterns in unit tests. That's what James Carr is up to here.
Patterns are everywhere and people have been putting togther catalogs of patterns and making them available to everyone (usually through something like a Wiki). Examples can be found here, here, and here. As an off-shoot of pattern catalogs, there are also Anti-Patterns. These are the alternate universe evil version of patterns (yes, just like the evil Spock) and I'm sure you've written them (I know I have). There's a category of Anti-Patterns here and a great site about Anti-Patterns here (including information about Anti-Pattern books).
TDD has patterns, or rather we refactor our code (an exercise in TDD) to patterns. Much like how I described the Split Loop pattern. You see something that smells bad, and think of a way to make it better. Applying a pattern to it is like taking a template idea (one that's been proven time and time again) and adjust it for the situation. Think of patterns as recipes as in baking. They're not rules but rather guidelines as to how to do something. Like baking you might add a dash of this or a hint of that to spice things up. With patterns it's the same thing and you adapt and make small corrections in applying a pattern to your style.
However we can also look at code and see Anti-Patterns. The evil under-doings of things done poorly. Things like the cut and past programming (how many times do you see this?) or the Golden Hammer pattern (where everything is a nail even if it looks like something else and you apply one technology to make it work, can someone say DataSets everywhere?) are examples of development Anti-Patterns.
In TDD there are also Anti-Patterns that crop up. This might be the result of getting to deep into trying to write a piece of code to test and forgetting about what you're really accomplishing. The Mockery or Excessive Setup Anti-Pattern touches on this. Imagine mocking a factory that mocks several calls to each of several factory methods, which returns several mocks, each with several exceptions... Even reading that makes my head spin. And the end goal? Assert.AreEqual(true, businessObject.Value). Craziness!
James has put together a collection of his own (and others) TDD Anti-Patterns. The discussion has been going on in the TDD mailing list for awhile so here's the collection of them. James is looking for some feedback on this so please look at contributing. It might become another catalog resource that we can all use. It'll be great to see this expand as examples are produced complete with refactorings to get yourself out of this TDD Hell.
No, I don't suggest you refactor "to" Anti-Patterns. That was just a title for this blog entry. Rather check out the list and either see if you can contribute to it or maybe use it to find your own code smells in TDD code you've written. You can check out his list here.