Good point.

I hate it when people write tests to cover every single function (to cover every line of code) but they pay almost no attention to the range of inputs/arguments passed to those functions.

I think that most bugs in production can be traced back to "An unexpected argument which was passed to a complicated function/method" - According to this, you should focus your testing efforts on methods/functions that have complicated logic and you should test them with a range of unusual arguments/inputs.

Writing tests for EVERY function/method using only obvious (common use-case) arguments is a waste of time.

He/she probably used a tool to capture the coverage %.

That only rephrases the question to what definition the tool used.

This comment reminds me of a typical response from a politician to a pressing question.

Sorry for the very literal answer. I honestly thought you were interested in how the coverage was calculated.

As an aside, I've worked on projects where coverage wasn't used and the rule was to "test the important bits" and I've also been on projects where coverage had to be >= ~98%. I wonder if a middle-ground approach would be effective.