Code coverage is important. I encourage anyone to do it, and I think it's an easy and valuable practice to keep for any software team. I am also no...
For further actions, you may consider blocking this person and/or reporting abuse
I always try to be conscious of point #3 when writing tests. By just creating an object you can execute many lines of code but verify nothing in your test at all besides the fact that your class compiles and the app doesn't crash.
In my opinion, code coverage tools really shouldn't even be seriously used until you're going about maintaining your suite of tests. If you write good tests to begin with and follow TDD principles you're going to end up with good code coverage without having to monitor your coverage reports at all.
In my experience, attempting to improve code coverage of legacy software is usually premature.
That's because it's often definitely known that the feature coverage is incomplete: there are untested features.
In that circumstance, measuring code coverage may be harmless, and can be helpful. (Hint: the coverage should be improving.) But the better guide at that point is the feature coverage.
So: pay primary attention to feature coverage, secondary attention to code coverage.
And always (as my boss DonD used to say), "Run your business not by the numbers, but with attention to the numbers."