“Instead of thinking about a design that would work for every nuance of a system,
test-first programming enabled me to make a primitive piece of behavior work correctly
before evolving it to the next necessary level of sophistication.”
If a piece of code survives long enough to deserve some refactoring, then i take a closer look at the patterns.
Take a look in Martin Fowler's Refactoring: Improving the Design of Existing Code and Refactoring to Patterns by Joshua Kerievsky. These in turn reference the GoF Design Patterns book so get that too.
If you can beyond the basic Rename Feature and Extract Function then you might be onto a winner.
If you intend to develop using TDD there is no doubt that you have to create your tests first.
It will let you implement the repository pattern naturally and will make your life easier as the repository pattern will make unit testing less painful.
Even the TDD test cycle enforces this order:
The repository pattern would be introduced in steps 3 and 4. when you actually write your code.
While I prefer those patterns to be introduced in step 4, some other people would just jump ahead and implement it in step 3. It's a matter of style, but I prefer the more complex code to be introduced once the unit test passes.
If you want to get a deeper understanding of this topic, there are some formidable books about refactoring, but one might be especially interesting for you as it logically binds refactoring and design patterns. Refactoring to Patterns
I have implemented the repository pattern in TDD development myself a few months ago and it worked out just fine.
I think this is an excellent question, so thanks a lot for asking it.
I'd stay away of patterning your coding too much by upfront design pattern usage. It is better to just make simple code and when needed refactor towards a design pattern that then captures your requirements best.