Test Driven Development
Test Driven Development
The .NET Q&A Blog is now live. It started with an idea that Jay Kimble had to start a blog dedicated to answering questions anyone may have regarding any issue in .NET. The idea is simple, you can go to the blog and use the Contact link on the side to email your issue. The issue then gets stripped of any project specific information (for the protection of the inocent) and posted to the blog for all the other bloggers out there to respond to. The advantage of doing this in a blog is that google seems to index blogs better than forums, so it will be easier for others to find these answers in the future.
In my previous post I was discussing my initial feelings about using TDD as a development methodology. I just finished reading a post by Steve Eichert which really sums up my feelings.
I haven't been this excited about coding in a long time!
I have completed my first production module using the test driven development methodology. I had some qualms about using this approach as it seemed like a waste of time to go through all the Red, Green, Refactor steps. It was a little frustrating at first, but as I got into the rhythm of it, I found that not only was I producing code faster than I have in the past, I was also producing much better code.
One of the biggest obstacles I face when doing a project is over-analyzing every aspect of my architecture. This leads to approaching a problem and debating with myself for endless amounts of time over which solution to implement. The drawback to this (besides the obvious fact that I'm spending more time thinking about solutions than coding) is that my solutions don't REALLY solve the problem I'm facing. They solve the problems that I perceive. By approaching each step in the process and solving only that problem using the TDD methodology my code now conforms better to the spec and not to my interpretation of it.