IME, nobody reads the tests in code review either. They just see "looks like it has tests" *check*. Many times, I've caught LLMs writing completely vacuous tests for configurations of components that were impossible. But coverage number go up, so those tests get written.

I've thought about this, tests should be easier to add to your modules. We dont' need a ton of tests, but we need them to be in more places.

Tests fix how the software can be changed and when software-spec evolves lots of tests can become obsolete. Maybe with AI it is easier to change the tests (?) which is good.

But there is another purpose for tests, besides "testing". It is to document your modules in a way that shows you how to use them, and let's you easily verify is this still working, can I trust it.

I was reviewing some coordinate conversion code one time and a developer’s method of creating unit tests was to run their code, generate a result, then make that output the correct result for the test. Except the result was wrong based on other utilities doing the same conversion, and also failed edge cases.

I've seen a coworker ship a test that contained a=1; assert a == 1.

Yes it was vibe coded. The "a" variable was never used, and was tested to be 1 several times.

It was several hundreds lines of course so I didn't bother reviewing the rest.

Test cases are an indicator. They say that this situation I thought of works as I think it should. It doesn't cover everything, but it does cover a large number of things.

A test is mostly useful only in the case that by failing it alerts you to a bug.