I find that some forms of writing code lend themselves better to TDD than others. Especially, red-green refactor testing.
In Red/Green refactor, I start with all my unit tests in place and failing (red). Then I implement my code until all test pass (green).
For example, if I have an interface that needs to be implemented 10-20x then I simply implement the interface in a class, which sets all methods to throw NotImplementedException. Then, create a test for each public method. From there, I just write the code to fix the tests.
Processes aren’t always so straight forward. For example, I’m writing a basic Excel parser. I’m not familiar with the Excel Interop API. I find it easier to simply write code. Then, through trial and error I discover my class design.
In this case I am writing some junk software. Prototyping it out just so I can figure out what my design needs to be. (Maybe I need to pass in a fileName here, maybe to this constructor…).
Ultimately, I would like to keep TDD. I do believe it keeps my code minimal and lean.
Does TDD work for prototyping? In other words, is there an approach I can follow so as to allow TDD to work for me even when I am not entirely sure where my design is going?
Yes, but do it like an API. Instead of guessing how to do something with excel, decide what you want to do as an end result. (Example: Read Cells A0 to A100)
Then as you go along with how it will work behind that interface, you will end up seeing what it is you can break off and test by itself, and possibly what might work better for the design. (Example: write code to read 0,0 to 0,100 and remove the letter code as it is more complex without any gain)
Don’t be afraid of invalidating tests due to design/behavior changes, they are there to help, not be concrete. (Example: That original test to read cells A0 to A100 should be deleted)