I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
Coverage is, in most cases, measured in one of three ways:
What percentage of functions are run by tests.
What percentage of control flow paths are run by tests.
What percentage of lines are run by tests.
The third option is the hardest to implement, but is usually overkill. Most tools implement the second option, as it's generally the most useful.
As far as how much testing should cover, that's rather subjective. The 'correct' answer is 'as much as you can cover without wasting time during testing or writing the tests', but that's not all that realistically useful.
The general idea is that you want to cover as much as possible, but you also don't want to waste lots of time covering that last 1%, and you want the tests to run fast enough that you can run them regularly (because otherwise they won't get run, which defeats the point of having the tests).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Coverage is, in most cases, measured in one of three ways:
The third option is the hardest to implement, but is usually overkill. Most tools implement the second option, as it's generally the most useful.
As far as how much testing should cover, that's rather subjective. The 'correct' answer is 'as much as you can cover without wasting time during testing or writing the tests', but that's not all that realistically useful.
The general idea is that you want to cover as much as possible, but you also don't want to waste lots of time covering that last 1%, and you want the tests to run fast enough that you can run them regularly (because otherwise they won't get run, which defeats the point of having the tests).