Here are some of the arguments I often hear in the context.
Having good test coverage doesn’t mean your code is well tested
One of the most common arguments, and yes, I know. Everyone knows.
It’s up to people responsible for tests to ensure tests explore good and bad code paths and the appropriate edge cases.
Full test coverage does not replace manual testing / whatever
Also a common argument, and yes, I know. Everyone knows.
No one I know has ever said that it is enough to have 100% coverage. The 100% coverage report is just one additional QA tool. In my humble opinion, and for some people, an important one.
Do you really test all your getters and setters?
Another argument that is often brought up.
If your getters and setters never do anything and never will, why even have them? Use public member variables. It’s possible to break during debugging when a variable changes the value. The "I need it for breakpoints" is therefore not an argument.
If getters and setters shall be future-proof, they are part of a contract with expected behavior, and that should be tested. If they do not only set and read values, they should have tests in any case.
This is maybe C++ specific, but can also be valid for other languages. Do you check that default constructed objects have proper or expected initial values? I have been bitten by that, and that hurt.
There might be more reasons why 5 to 10 minutes' time investment per class to test set and get property values is not a bad idea. But if it’s really too much work, just exclude them from coverage reports. More on that later.
Some code is not reachable via unit test
Yes, of course. And I agree that can be a challenging topic. And there is no one answer or argument for all types of projects.
For some code parts to be reached, you need to run integration tests. Or even manual tests.
But if there is no way to reach some code, it might be a good idea to think about removing those parts.
As a side note: Sometimes it is interesting how much code can be found in old legacy projects that do nothing other than confuse the people working with the project and cause huge costs.
There are always exceptions, and there are different types of code. GUI code is different than library code. GUI code can be difficult to test, do that automatically, and get good coverage reports. For library code, if it’s not possible to reach 100% of the implementation via the public interface, there might be a problem.
It can be difficult to reach full coverage reports, even with the possibility of merging coverage reports from different testing stages. But that should not be a hindrance to aiming for as high coverage as possible, and often that can be 100%.
I need to ship yesterday
Yes, sometimes some projects or customers require quick and dirty solutions. Write once, ship, and pray for the best.
I feel kind of sorry for people who are in these types of projects, where this is the norm and not the exception. But I can understand that those projects or situations exist and that they have special rules.