Oh come on, people have been writing code with bad, incomplete, flaky, or absent tests since automated testing was invented (possibly before).

It's having a good, useful and reliable test suite that separates the sheep from the goats.*

Would you rather play whack-a-mole with regressions and Heisenbugs, or ship features?

* (Or you use some absurdly good programing language that is hard to get into knots with. I've been liking Elixir. Gleam looks even better...)

It sounds like you’re saying that good tests are enough to ensure good code even when programmers are unskilled and just rewrite until they pass the tests. I’m very skeptical.

It may not be a provable take, but it’s also not absurd. This is the concept behind modern TDD (as seen in frameworks like cucumber):

Someone with product knowledge writes the tests in a DSL

Someone skilled writes the verbs to make the DSL function correctly

And from there, any amount of skill is irrelevant: either the tests pass, or they fail. One could hook up a markov chain to a javascript sourcebook and eventually get working code out.

> One could hook up a markov chain to a javascript sourcebook and eventually get working code out.

Can they? Either the dsl is so detailed and specific as to be just code with extra steps or there is a lot of ground not covered by the test cases with landmines that a million monkeys with typewriters could unwittingly step on.

The bugs that exist while the tests pass are often the most brutal - first to find and understand and secondly when they occasionally reveal that a fundamental assumption was wrong.

Tests are just for the bugs you already know about

They're also there to prevent future bugs.

So is here to stay. If you’re unable to write good code with it. Doesn’t mean everyone is writing bad code with it.

Too bad no one will be able to read it. Better make it a video essay.

with subtitles flashing in the center of the screen