I try to do TDD as much as I can. But sometimes (for example last Friday) I don't know how to get started. This happens when I don't have a plan of how the code should look in the end, possibly because don't completely understand part of the problem. Especially I didn't know how I would be able to test it, due to the fact it the code had to interact with a different system and a database.

The pragmatic programmer recommends a tracer bullet or spike in this case. This means you implement some kind of prototype in order to clarify how to implement it properly.

And than you throw that away and implement it properly again, which for me means test driven.

Do you really do that? For me this goes against the principle of baby steps and of refactoring instead of rewriting code.

Also I was fearing it wouldn't help much, because the problem wasn't so much that I was unclear about the code, but about how to test it.

So last Friday I tried a different approach. I call it 'Sketch and Test'

I started by implementing the complete thing in one single class. Without tests (scary, I know). But I never actually executed the code. I just wrote it as I thought it should work.

Once this sketch was finished I looked at the code and considered the changes I needed to make in order to test it.

I did the changes and finally created the tests, fixing the bugs I found in the progress.

Only when all the tests where in place and green I actually started the application and tested the new feature.

It worked, i.e. the feature did what I expected. The code qualifies as clean and I had complete code coverage with the only exception of some weird exception handling code, that I found hard to trigger in tests.

What do you think? Is this a viable approach? Or is it just a symptom of my limited TDD skills? Or both?