Test Driven Development Pros And Cons

I am a fan of TDD (Test Driven Development), for those who don't know TDD here is the places to read about it:

Test Driven Development by Kent Beck

The Three Rules Of TDD by UncleBob

You are not allowed to write any production code unless it is to make a failing unit test pass.
You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

Three Monkeys of Test-Driven Development by Ashutosh Nilkanth

You basically make sure everything works before doing anything else; and you only do one thing at a time. It has the great advantage that you can change whatever you want in your code and you can be sure it is as good as before. This allows you to aggressively refactor. Being able to refactor without fear of breaking something should leave you code easier to maintain and easier to add new features. This will hopefully overcome the time it has taken to write all those tests in the first place.

A few things make TDD more difficult:

Randomness (Non-Deterministic Methods)
User Interfaces
External Code (including Databases)

It is for this reason that I find it difficult to use TDD for all my coding. Now those who support it say that you can mock up facade classes for the external code including random number generation meaning you can test only the bits you want.

My other problem it it seems to break my flow of thinking. I want to type out a load of different ways of doing things and see which one I like better.

I think TDD has it's place but there is a need to do another kind of programming. Exploratory programming; one where you do not know what you want to end up with. You just chuck out a load of code and see how it runs. This is great if you have a nice fast development cycle, i.e. interpreted high level language. I would say that it get exponentially more complicated to do exploratory programming as the total number of lines of code increases. This gives a natural limit to the kind of things that can be accomplished with this technique. I believe it is best suited for tracers and prototypes (see The Pragmatic Programmer). In this case you quickly see the shape of a small part of your program and begin to see what things (modules, classes) you need in the full version. Once you have got a section of code working you can write it properly (with TDD) meaning you live by the rules of TDD and throw one away (Mythical Man Month).