Coverage is not a good metric if followed strictly. It ignores the significance of the code being covered, giving equal value to places that are complex and those that are trivial. It creates a bogus priotization for what to test.
In the general sense of the word "coverage" we do want "full" coverage. You should test all your code to some degree.
Here are some practical tips:
Ensure common use-case paths are covered. If it's written in a high-level feature then it should somehow be tested.
Avoid testing unexpected error conditions throughout the code. That is, if you have error detection code, and you do because you're doing defensive coding, it's a very low value proposition to ensure those checks work.
Avoid testing trivial code directly, assume transitive testing of classes will cover them, or even just rely on code review to catch obvious mistakes.
The extent of coverage relates to the complexity of the module. An algorithm that took a week to get right requires enough tests to verify its correctness. Some unavoidable boilerplate code may not need much, if any at all.
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 not a good metric if followed strictly. It ignores the significance of the code being covered, giving equal value to places that are complex and those that are trivial. It creates a bogus priotization for what to test.
In the general sense of the word "coverage" we do want "full" coverage. You should test all your code to some degree.
Here are some practical tips: