I know Devel::Cover in fact we've it tied to Hudson continuous integration server to automatically generate coverage report for our app ( Hudson also does perldoc, load testing and profiling using Devel::NYTProf).

The whole point is to avoid becoming obsessed about the 100% number, because it doesn't guarantees you anything. In fact most valuables test cases we have rarely increments the coverage % as they are border cases or special conditions of things that are already covered.

I don't think you have to aim to have 100%, I think you have to aim to have a consistent test suite where critical paths are good covered.

Ideally private methods are not tested directly, but what if you have the following code

sub method_a {
   ...
   open(...) or die "First ...";
   ...
   $self->_method_b();
}

sub _method_b {
   ...
   open(...) or die "Second ...";
   $self->_method_c();
}

sub _method_c {
   ...
   open(...) or die "Third ...";
}
[download]

Now you want to test an error condition in the third open so have mock of the open method and depending on the method's caller the open will return true or false, so your mock's code will have something like

if ( $caller eq '_method_c') {
    return 0;
}
return 1;
}
[download]

Indirectly your test code becomes dependent of _method_c (private method), as a rule of thumb the more nested private method calls you have the more complex the test case will become, sometimes it makes sense to test the private method directly.

There is a good article Give me 100% Code Coverage or Give Me Death!