I've been in more than a few places where tests were a net negative to the project. A poorly written tests can be worse than no tests at all.

Probably the most frustrated I've been in a code change is when a single line resulted in 10+ test files being updated (adding a parameter to a method call used in one place in the code...) This provided no actual benefit to the project at as a whole and was mostly just code churn.

What's worse, I've also seen places where there are a bunch of extra code paths added to support tests! In other words, code was made MORE complex simply to support tests. That's getting the cart before the horse.

Not to mention the times I've had to dedicate a significant part of my time fixing tests for a project because they intermittently fail (hurray for `Thread.sleep` in a test...) I wasn't going to work on the project when it would randomly fail unrelated to the code I wrote.

All this is to say like my original comment, there's no one metric you can look at and say "yeah, this is good code".