interesting perspective - why do you think this is a bad thing?
to me, it's an opportunity to verify that the change is intended. without it, how do you know that the program does what it is supposed to do?
Thinking of it as a leaky abstraction helps me.
I try hard to separate domain logic tests from implementation specific tests.
Your code could be loosely coupled with high cohesion, but with lots of random tests like you get when code coverage is a performance metric, you have to add a lot of complexity that only relates to an implementation.
People then get used to just blindly updating the golden images. It becomes basically "the output changed, do you want to continue anyway" which is not the most useful thing. You really want it to say "the output is wrong".
I don’t want to write tests for everything. I just want to write the ones that matter.
TDD is _about_ writing tests that matter, but most people think it is about writing all unit tests first.
If you are following TDD anywhere close to the way it is described, you will only be writing tests that relate to domain functionality first.
Note how it is described here, although it is turse.
https://martinfowler.com/bliki/TestDrivenDevelopment.html
The coverage metric as a goal writing style doesn't work for TDD, sorry you were exposed to that.
You are correct that model doesn't work.
Coverage is not a goal of TDD, but in practice you will have 100% coverage by following TDD as you would never have reason to write code that isn't covered by test.
Ultimately, the purpose of coverage tools is to let you know what you might have forgotten to clean up during a refactor, to help you remove what you missed.
More importantly, why are you writing any code for things that don't matter?
Another way, if you know what the code is supposed to do, why write it down in two places?
This would be like criticizing double-entry accounting by asking "if you know what the amount is, why write it down in two places?"
We write the code down in two places because that gives us advantages that far outweigh the added effort:
- Once written, your test will catch regressions forever
- A test is often excellent documentation on what the code does
- It's now much easier to refactor the code, making it more likely that it will be refactored when needed.