Re^2: Making open fail

Although I agree that you should try to get a good coverage I wouldn't pursuit the 100% itself. Let's consider the following subroutine

sub divide {
    my ($a, $b) = @_;
    return $a / $b;
}
[download]

You can easily create a test case and get a 100% coverage, and as you might realized the code can still fail ( if $b is 0 you'll get a "Illegal division..." ), here the 100% gives you a false sense of security. On the other hand the more tests your application has the harder it is to change it or refactor it

My point is you shouldn't blindly follow best practices, they are just a guide not a law (use your own criteria). Don't use test coverage as a goal itself, otherwise you would end up writing code to get 100% coverage instead of writing code to perform a task

Comment on Re^2: Making open fail Download Code

Replies are listed 'Best First'.
Re^3: Making open fail by DrHyde (Prior) on Jul 05, 2010 at 10:26 UTC
On the other hand the more tests your application has the harder it is to ... refactor it On the contrary, the more tests you have (or rather, the better your test coverage), the easier it is to refactor. Refactoring should involve no changes to the code's function, and the better your test coverage, the easier it is to rearrange the code without unwittingly breaking it.	[reply]
Re^4: Making open fail by bluescreen (Friar) on Jul 05, 2010 at 13:15 UTC
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	[reply]
Re^5: Making open fail by SilasTheMonk (Chaplain) on Jul 05, 2010 at 14:50 UTC
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.	[reply]
Re^6: Making open fail by bluescreen (Friar) on Jul 05, 2010 at 18:30 UTC
Re^3: Making open fail by SilasTheMonk (Chaplain) on Jul 04, 2010 at 21:50 UTC
bluescreen, I absolutely understand where you are coming from on 100% test coverage. It may be fairer to say I am experimenting with it. I have all sorts of thoughts on the subject. For a start with a new module it is straightforward, to keep the test coverage up to 100%. For an older module you can only hope to approach it aggressively. It is interesting to take a module that you regard as critical, and run Devel::Cover on it - and to compare the results with the bug list - and to ask how many of those bugs could have been avoided with better testing. When I have done that and tried to discuss the results, the responses such as they were struck me as complacent. Also I am working on restructuring and improving CGI::Application::Plugin::Authentication. As a I did not write that module originally, getting the test coverage up seems a constructive way of knowing and controlling the impact of my changes.	[reply]