>I've often figured out late in the game how to make something a compile time failure rather than a runtime one
This is actually a good (albeit somewhat niche) reason to not write a test scenario at all, but it's still not a great reason to write a test after instead of before.
>Fundamentally the goal of testing is to describe what behaviors of the software are intentional rather than incidental
Yup. A test scenario which is of no interest to at least some stakeholders probably shouldnt be written at all.
This is again about whether to write a test at all, though, not whether to write it first.
>TDD mixes both concerns
I dont think writing a test after helps unmix those concerns any better.
In fact it's probably a bit easier to link intentional behavior to a test while you have the spec in front of you and before the code is written.
I find people who write test after tend to (not always, but strong tendency) fit the test to the code rather than the requirement. This is really bad.
>Maybe other people work on different types of things and TDD is great for them, but I write primarily infrastructure code where correctness is critical and I have the luxury of time
Assuming Im understanding you correctly (you're building something like terraform?), integration tests which run scenarios matching real features against fake infra would seem to be pretty useful to me.
So...why wont you write tests with that harness before the code? Im still unsure.
The only thing "special" about that type of code that i can see (which isnt even all that special) is that unit tests would often be useless. But so what?
This is actually a good (albeit somewhat niche) reason to not write a test scenario at all, but it's still not a great reason to write a test after instead of before.
>Fundamentally the goal of testing is to describe what behaviors of the software are intentional rather than incidental
Yup. A test scenario which is of no interest to at least some stakeholders probably shouldnt be written at all.
This is again about whether to write a test at all, though, not whether to write it first.
>TDD mixes both concerns
I dont think writing a test after helps unmix those concerns any better.
In fact it's probably a bit easier to link intentional behavior to a test while you have the spec in front of you and before the code is written.
I find people who write test after tend to (not always, but strong tendency) fit the test to the code rather than the requirement. This is really bad.
>Maybe other people work on different types of things and TDD is great for them, but I write primarily infrastructure code where correctness is critical and I have the luxury of time
Assuming Im understanding you correctly (you're building something like terraform?), integration tests which run scenarios matching real features against fake infra would seem to be pretty useful to me.
So...why wont you write tests with that harness before the code? Im still unsure.
The only thing "special" about that type of code that i can see (which isnt even all that special) is that unit tests would often be useless. But so what?