Studies on TDD has failed to show a benefit over writing tests after the fact. The only factor that seems to matter is writing tests, the more tests the better. If you can write your code so it's amenable to more testing, or such that it requires fewer tests because it's simpler/has fewer cases to handle, great. If you have a framework that can generate tests (fuzzing, property-based testing), awesome.
I'm pretty convinced that test-first is best seen as a negotiating technique to get the time to write the tests in the first place.
"Okay, the code is done, time to write the tests" results in pressure to shorten testing, since if the golden path works then surely everything else works, right?
Your management and your sales people then say "You're a great developer, it looks like it works, and we need to deploy that code now because customers are demanding it and the competition is breathing down our necks."
It's hard to resist that pressure.
While saying that it's best practices to do TDD means you don't need to deal with that sort of negotiation.
I can see that, but only because the dev has arguably already made the mistake of showing sales working features before tests are written. I've always been clear to say when something is a partial mockup to verify that I've understood what they're asking for.
Yes, but many places don't have a healthy work environment, and developers are generally younger, less confrontational, and less experienced at negotiating than management and sales.
True that. One of the major factors of my success as a software developer is a lack of fear (either through stupidity or bravery) of "taking on" toxic/unfair/destructive environments and people.
Yeah, that's something I've been promoting for years. I don't care whether you write tests first or last, as long as you eventually get into a feedback loop of coding and verifying your code, quality will improve.
The same goes for customer specs. Just build a thing and verify if this is right.
