>The code I write initially can often be very dumb, repetitive and procedural. I often have to discover and see what the data structures really look like, what

>The code I write initially can often be very dumb, repetitive and procedural. I often have to discover and see what the data structures really look like, what the public API looks like, what I leave in code and what I want to be data driven etc. I do this plenty after writing a new (high level integration) test. Usually I have a fairly clear idea of what the public API I want should look like before I code. A test that calls that API makes a good test. I might tweak the way it is called when coding the implementation, but probably not by much. Underneath it the integration test doesn't care what kind of data structures you use and it provides a safety harness to let you discover at will. >At this stage it makes little to no sense to write tests first. All I need is to see the output, which might change dramatically during development. I frequently write the test first for this type of code - e.g. APIs that output JSON blobs or command line apps that output a wall of text. Where I'm expecting the output to change I program the test to temporarily overwrite it with the results of the program, eyeball the result and commit it all together if it's correct.