To quote Marilyn Strathern's phrasing of Goodhart's law: "When a measure becomes a target, it ceases to be a good measure." (source)
The goal is to have well-tested software, and code coverage (in one of many shapes) can be used as a metric for that. Or better: the lack of code coverage is a smell indicating that software isn't well tested. However, just because you haven't detected a smell, doesn't mean there isn't a flaw.
So sure, aim for 100% test coverage, but be careful to only use good tests (there are plenty of tests that cover a line but don't test it), and don't think that 100% means "job done". It's just that one of the check boxes has been ticked.
Side note 1: code coverage comes in many different shapes and sizes, with varying demands and usefulness.
Side note 2: I'm not entirely convinced that 100% should be the threshold value, always and ever. It depends on the kind of code and environment you're in, and should depend on the needs of you, the company, or the customer. I would suggest starting with a 100% goal, and see where that is or isn't feasible and where it is or isn't helpful. Maybe you should have different targets for different kinds of code, as testing everything upfront might cost more than fixing some things afterward.
In the same vein, doing a project in the waterfall style, UMLing all the things, once in uni made me a better developer, because I now have these tools in my toolkit. However, I wouldn't recommend anyone doing this in a production environment unless there is a strict need to design and document everything upfront (although I'm not sure if even aviation would require this nowadays).
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.
Yes, but also no. Or maybe a "Yes, but...".
To quote Marilyn Strathern's phrasing of Goodhart's law: "When a measure becomes a target, it ceases to be a good measure." (source)
The goal is to have well-tested software, and code coverage (in one of many shapes) can be used as a metric for that. Or better: the lack of code coverage is a smell indicating that software isn't well tested. However, just because you haven't detected a smell, doesn't mean there isn't a flaw.
So sure, aim for 100% test coverage, but be careful to only use good tests (there are plenty of tests that cover a line but don't test it), and don't think that 100% means "job done". It's just that one of the check boxes has been ticked.
Side note 1: code coverage comes in many different shapes and sizes, with varying demands and usefulness.
Side note 2: I'm not entirely convinced that 100% should be the threshold value, always and ever. It depends on the kind of code and environment you're in, and should depend on the needs of you, the company, or the customer. I would suggest starting with a 100% goal, and see where that is or isn't feasible and where it is or isn't helpful. Maybe you should have different targets for different kinds of code, as testing everything upfront might cost more than fixing some things afterward.
In the same vein, doing a project in the waterfall style, UMLing all the things, once in uni made me a better developer, because I now have these tools in my toolkit. However, I wouldn't recommend anyone doing this in a production environment unless there is a strict need to design and document everything upfront (although I'm not sure if even aviation would require this nowadays).