Maybe this is just a feeling only I have but TDD at its purest form is kind of demoware. Why do I say this? Well, take a look at all the TDD tutorials out there - it will usually be the chewed-up email sender or money transfer between accounts or some kind of blog. All of these are very narrow examples which are for, well, demoware…

Non of the examples above are of applications with a “big picture”. I find that TDD is not suitable for big pictures because when the picture is big, I can’t see the whole of it - I have to make some assumptions that I know are going to change soon. This is just something I have to do in order to control complexity and be agile.

When these assumptions change, code is going to change and in case I have tests, they have to change as well which means I had more code to start with and I have more code to change and this excessive code served no purpose! (since it had to change as well…)

Saying that does not mean I think tests are not important - I think they are important. Same goes for the design principles that TDD promotes such the SOLID principles - they are important.

I think that the shift to BDD strengthen my point as well.

So what do I propose? Quickly develop the first generation of your application. By that you will learn how your application should behave. With the insights you have gathered, write the tests for your application and refactor. I believe that way the test code will take less time to think about and will change less frequently.