[NortySpock]

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...)

[bo1024]

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.

[freeone3000]

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.

[collingreen]

> 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.

[candiddevmike]

Tests are just for the bugs you already know about

[thunky]

They're also there to prevent future bugs.