No, it doesn't.  Code Coverage tells you only that for the set
of executions you have tried, that some block of code has not
been executed.   It cannot tell you that for all program inputs,
the block of code can never be executed.    That's my
definition of "unused", and I think it matches what the OP
was looking for.

If you delete a function from your sources based on
test coverage "not executed" results, you may be setting yourself
up for failure in the field.   Most error handlers will
fall into this category.  You wouldn't remove error
handling code, would you?

That said, I believe test coverage is valuable; it gives you
a *hint* that the function might be "unused".  But it doesn't
answer the question definitively.

So the basic problem is, can you determine if the predicate
of a conditional is always true (false):
       if (p(x) { /* delete this if p is always false */ )

The tool we were talking about (removing unused declarations) doesn't do
this.

However, the problem of simplifying conditionals, and deleting disabled
code, can be handled (within Turing limitations and your sweat equity).
DMS provides general program transformation machinery, which includes
as a subset the ability to simplify expressions.     Certain classes of
expressions
simplify "easily" (e.g., 2+2==5 can be easily simplified to false)
and it is trivial to write rules that delete dead code, e.g.,
       rule delete_useless_ifthen(p: expression, b: block):  statement ->
statement
         = " if (\p) \b " -> ";" if simplify_to_false(p).
would do the trick for your first example.   You still need the useless
declaration removal logic, which would be triggered when the references
to unfetched/uncalled/unused vanish to delete their corresponding
declarations.

To handle the conditional instrumentation, you need to add constant
propagation:
       private ... testing=false;
       ....
       if (testing) { ... }
==>
      private   ... testing = false
      if (false) { ... }
and then the above mechanisms can finish the job.

DMS can support constant propagation, but you need control flow analysis (we
have it
for Java, but not quite yet for other languages).

However, we can take advantage of the fact the *you know* what the testing
flags are
in your application, to write "idiomatic" transforms to do this job.

As a simple example, we can implement your removal of conditional
instrumentation
by merely adding the rule:
      rule testing_is_false():expression->expression
     = "testing" -> "false".
under the assumption that "testing" identifier is unique across the program.
This rule has the effect of propagating the "interesting" constant
everywhere.
Combined with delete_useless_ifthen rule above, and the delete useless
declaration logic, you can get exactly what you are looking for, with darn
little effort.
(Two rules, both of which I've given to you!).

We've used this technique to eliminate dead configurations (as defined by
preprocessor conditionals) from large C and C++ systems.