30 Days of TDD – Day 25 – Reader Question #1

If you’ve never done Test Driven Development or aren’t even sure what this "crazy TDD stuff” is all about than this is the series for you. Over the next 30 days this series of posts take you from “I can spell TDD” to being able to consider yourself a “functional” TDD developer. Of course TDD is a very deep topic and truly mastering it will take quite a bit of time, but the rewards are well worth it. Along the way I’ll be showing you how tools like JustCode and JustMock can help you in your practice of TDD.

Previous Posts in this Series:  30 Days of TDD – Day 24 – Strictly Mocking 

Question #1

Mike Shepard asks:

Do you think that having well written (and thorough) specifications are a necessary condition to using TDD?

In my experience I have rarely seen a system that is fully specified enough to write unit tests sufficient to cover all of the system behavior.

Thanks for your question Mike.

I think it’s important to have a good understanding of the system or application you are trying to build up front. I also think it’s a good idea to have an idea what your requirements and specifications are going to be as soon as you can. However I also understand that in most systems this is not possible or practical. Things get missed, forgotten and overlooked all the time. This is one of the things that agile methodologies like Scrum try to address.

My goal with TDD (and by extension, agile) is not to try to define every possible detail of the application up front. Instead I try to get as much information about the application I’m building as I need to get started. From there I try to address the application in a feature by feature basis.

Taking that a step further, I’m not trying to derive every test condition of my application up front either; just the specific system behavior I’m addressing at the moment. This saves me from getting into a never-ending loop of requirements gathering (analysis paralysis) and keeps me from worrying too much about features in my application that my never actually get scheduled for development.

Continue the TDD journey:

• 30 Days of TDD: Day 26 Reader Question 2