4 ms·

I have to disagree with that last statement. The code I write initially can often be very dumb, repetitive and procedural. I often have to discover and see wha

by dgb23 4y ago

I have to disagree with that last statement. 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. 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. It’s a very fast, direct way of programming, with a lot of copy pasting and long parameter lists. When the code is laid out like that, then I can see where it’s going. I see the repetitions, the edge cases etc. Now it starts to make sense to design the data structures, give declarative names, find the right abstractions. Now I can move forward with tests.

mettamage 4y ago
That first phase is what I call “playing around”. A necessary phase. When you explore/play one shouldn’t test because one is learning. Testing (aka evaluation) should happen when one knows the routine + outcome you want to evaluate that routine one. Whether it’s code or improving your singing or learning in school. This generalizes to all of that, IMO
pydry 4y ago
>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.

by dgb23 4y ago

mettamage 4y ago

That first phase is what I call “playing around”. A necessary phase. When you explore/play one shouldn’t test because one is learning. Testing (aka evaluation) should happen when one knows the routine + outcome you want to evaluate that routine one. Whether it’s code or improving your singing or learning in school. This generalizes to all of that, IMO

pydry 4y ago

>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.