One of the suggestions that the authors of Test Driven Development in .NET, as well as Ron Jefferies in Extreme Programming Adventures in C#, make is to start simple. Rather then writing a full test that tests all the advanced business logic in your objects start with something simple. Write a test that confirms your most basic assumptions. Although at first it seems like a waste of time these simple tests get the ball rolling. TDD is about getting into a groove, red...green...refactor...red...green...refactor. One of the barriers that I often run into is all the thoughts that are running around in my head. Should I choose architecture A, or architecture B? Which one fits the current needs, which one fits the direction I think the application will end up going? What can I optimize, how can I reduce database hits, how can I make this look cleaner, how, how, how...but...what if....?
All these thoughts stop me from doing the most important thing, writing code. I often get caught up in trying to figure everything out before I write a line of code. I think some of this can be attributed to the way many of my peers did things during the time when I was learning the ropes. They've scarred me...them bastards! Rather then trying to figure out everything before you start coding I highly recommend starting with something simple. As the application evolves so to will your code. If the application really needs “that elegant design” you'll know it. Do yourself a favor and start simple.