Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re^4: Lessons learned from getting to 100% with Devel::Cover

by belg4mit (Prior)
on Jul 30, 2004 at 14:06 UTC ( [id://378694]=note: print w/replies, xml ) Need Help??


in reply to Re^3: Lessons learned from getting to 100% with Devel::Cover
in thread Lessons learned from getting to 100% with Devel::Cover

That may just be a stupid example, but testing that die happens?! Why on Bob's less than green Earth would you nay should you do that? Testing your code should not ammount to testing the local perl installation.

--
I'm not belgian but I play one on TV.

  • Comment on Re^4: Lessons learned from getting to 100% with Devel::Cover

Replies are listed 'Best First'.
Re^5: Lessons learned from getting to 100% with Devel::Cover
by adrianh (Chancellor) on Jul 30, 2004 at 14:27 UTC
    That may just be a stupid example, but testing that die happens?! Why on Bob's less than green Earth would you nay should you do that?

    Because testing the case when some_function() returns false is useful. What should happen? Should the program exit? Should the exception be caught? Is a false return value even possible?

    The whole reason I wrote Test::Exception was to make testing this sort of thing easier :-)

Re^5: Lessons learned from getting to 100% with Devel::Cover
by stvn (Monsignor) on Jul 30, 2004 at 15:22 UTC
    That may just be a stupid example, but testing that die happens?! Why on Bob's less than green Earth would you nay should you do that? Testing your code should not ammount to testing the local perl installation.

    I think you misunderstood. The idea is not to test that die happened, but to test that in certain exceptional circumstances, your code will die. The errors you throw/return/raise and the conditions that lead to that happening, are just as much a part of your code as the rest of it.

    Not testing how your code handles an error, would be like an automaker just assuming the airbags, and crumple free zones work.

    -stvn
      I don't believe I did, you've just restated the same thing you claimed was not the purpose in a different manner. EXPR logicop die;. Doesn't seem too complicated to me.

      --
      I'm not belgian but I play one on TV.

        The idea here is to test whether EXPR ever actually becomes false — and particularly whether it becomes false on the input for which you expected it to do so. The question your test is asking is “assuming known bad input, will the program actually blow up as it should?” The alternative is that it will silently continue running with bad data.

        You should always check that your program not only works correctly with correct input, but also that it blows up where it should. If you wrote a square root function, the tests should not only check that you get 2 when you pass 4, but also that you get an exception when you pass -1 (unless we're talking complex numbers, but let's not take the example too far). It would be disastrous if you go into production with a square root function that happily produces a result (from among the set of real numbers, anyway) when passed -1.

        Makeshifts last the longest.

        EXPR logicop die;. Doesn't seem too complicated to me.

        It doesn't need to be complicated for you to still test it.

        Besides its less about testing a single line, and more about testing how that single line interacts with all the code that comes before and after that line and how they handles the circumstances which created the error condition.

        -stvn

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://378694]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others rifling through the Monastery: (5)
As of 2024-04-16 19:37 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found