His steps for successful TDD are: write a test, make it pass, refactor. A suggestion he made was to name a test after the feature you are testing instead of the method. Here also, a good rule of thumb is: err on the side of verbosity.
By writing tests, functionality can be described and added in small pieces.
After that you refactor them by replacing duplicates and making stuff as expicit as possible.
In conclusion he said that writing tests does not add enormously to development time, because research has shown that most of the time we read code more than we write it.
Too bad the session ended with a negative atmosphere because James Coplien had a difference of opinion that got fought out amongst the audience which I found to be very unprofessional.