Let's consider you write test cases for private methods, and you have a bunch of them ( test cases and private methods), and then you try to refactor and you delete some of the private methods and create new ones, in that scenario you'll have a bunch of failing test cases you will have to fix, even worst if you are refactoring not just an isolated module but a whole part of your app

Don't get me wrong, its all about balance and putting more test cases where it worth it ( riskier code ) than just putting a lot of test cases everywhere

hmmm... I wonder if there is some confusion going on here. The way Devel::Cover measures test coverage is what percentage of the lines and branches in the code are executed by at least one test. If you tried it you would see how it works. Ideally private methods should not be tested directly - only indirectly - because they are private methods. That may not always be possible but it should be most of the time.

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!