Kent Beck talks about this in episode 1 of http://pragprog.com/screencasts/v-kbtdd/test-driven-development http://pragprog.com/screencasts/v-kbtdd/test-driven-d

Kent Beck talks about this in episode 1 of http://pragprog.com/screencasts/v-kbtdd/test-driven-development http://pragprog.com/screencasts/v-kbtdd/test-driven-developm... The example he works with is writing a driver for Tokyo Tyrant in java. He begins by writing a high level test of what he eventually wants to be able to do. Instead of implementing it though he comments it out and then starts to play around with potential implementation code inside the body of the test. Once he's finished playing he then gradually refactors code from the test body into the implementation until he's got everything he needs and uncomments the test. It may well be the case that by the time you've finished exploring that you've realised the test you've written isn't very relevant. This is fine, the purpose of the writing the initial test is to guide your exploration in a productive direction. Once you have some implementation code you can always go back and reframe the test according to your new understanding.