I once worked with a guy who took the opposite approach: I had a PR that made some simple changes to existing code to make it possible to test it. He refused to approve my PR, because he considered this cheating.
There's even better approach for big companies with huge budgets that need to get products right:
Get validation team as an addition to your own tests.
You start with specification and both teams - dev and val start developing parallelly.
They'll develop their own tests, then review your code with huge focus on finding bugs, security issues and so on.
> Bebugging
Should not the verb be "to embuggen", the participle being "embuggening"?
It might be a good idea to try vf-vibe-coding
I'm all for splitting up the definitions of "test-first development" (TFD) and "test-driven development" (TDD), because I think for many forms of software development TFD is an anti-pattern that actively discourages people from writing tests.
Unfortunately this article appears to want to treat TDD as a sub-set of TFD. I'd like to redefine TDD to mean "you bundle tests with your implementation when you commit to source control" - where it doesn't matter if you wrote the tests before or after the implementation.
I write a lot of my tests after, often using snapshot testing. I get the key benefits of a robust test suite - protection against future changes introducing bugs that my test suite would have caught - but I don't go through the torment of trying to figure out how to test something that I've not yet even fully designed.