I cringe at this as much as you do but for the 20-year old MBAs that make the calls that’s valuable because it reduces time to market.
And sadly for me and you and others of the same mind, this actually works. If you produce a product that works well 70% of the time and people pay for it, they are willing to forgive its defects until you fix them (if you ever do).
Maybe we’re just badly adapted to this world, I fear sometimes. 
The reality is more simple, software industry has such a huge margin of profit, that it is actually encouraged to write bad software, just later ti switch to yet another sponsored solution that fixes it all.
Imagine if all concurrent java codebases were to run stable on erlang VM, how many artists were to lose their paychecks?
Well that’s kind of what I said – this approach that you and me and others hate actually works in terms of a business model. Which means that people will practice it until it stops working.
As a funny (second hand) side story, my friend told me a pretty ridiculous story from when he worked on a very large enterprise application. He was advocating for doing some preparatory refactoring to make a new feature easier to implement. The response was, “We don’t refactor here because if we do then we’re required to run ALL the tests.” My friend asked why that was a big deal and how long that would take and the answer was “3 months.” “Running all the tests” meant having the QA team work through a playbook of thousands-upon-thousands of hand-written scenarios. Whatever works, I guess 
I look at my code and see what things I expect to do. I may also add tests for things I expect the code NOT to do. Then I make a test for each of those things.
Like, say you have an add/2 function that adds 2 integers. What do you want to be sure will happen when the function will run?
You want it to:
So each of those is a testable thing, and you could have a test block for each item (I would give more in-depth examples but I’m on mobile).
So it’s basically like that for each “thing” your code does. Every time you run the tests, you are essentially writing some (test) code that ensures that the (production) code does what you think it does. Your tests are like little minions that ensure that nothing breaks when you change something.
Your tests are like a mirror image of your code. In the code you implement a given feature. In the tests, you verify that each feature works as expected.
Typically, I prefer to write a given feature or module, then write the tests (as opposed to writing one piece of code, then one test, etc.).
With good tests in place, if you change the code and tests break, you’ll know that either your code is wrong and need to be fixed, or the tests have become wrong and need to be fixed.
Primeagen? Marc Lou?
—
Thanks for all the insights and links. I think I’m beginning to see my path; I’ll think of each acceptance criteria as one test.