Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

testing a croak

by arcnon (Monk)
on Jan 19, 2006 at 05:31 UTC ( #524131=perlquestion: print w/replies, xml ) Need Help??

arcnon has asked for the wisdom of the Perl Monks concerning the following question:

how do you write a test that doesn't cause the test script to die? I am using croak in my sub. What is the best way to do this?

Replies are listed 'Best First'.
Re: testing a croak
by tirwhan (Abbot) on Jan 19, 2006 at 06:39 UTC

    You can use the Test::Exception module and test with either dies_ok(tests for death) or throws_ok (tests for death with a specific error message).

    use Test::Exception => 1; throws_ok { dying_sub() } qr/I always die/, "sub dies with correct err +or message";

    There are ten types of people: those that understand binary and those that don't.
      I tried test exception but it kills the script

      if I comment out this test

      All tests successful.

      Now with the test

      ... use_ok( 'Test::Exception' ); ... throws_ok { $objRef->parse_date_string() } qr/improper initialization +please see the docs/, 'checking 2 few args'; t/01-object....ok 1/23improper initialization please see the docs at t +/01-object.t line 56 # Looks like your test died just after 23. t/01-object....dubious + Test returned status 255 (wstat 65280, 0xff00) after all the subtests completed successfully Failed Test Stat Wstat Total Fail Failed List of Failed ------------------------------------------------------------ t/01-object.t 255 65280 23 0 0.00% ?? Failed 1/2 test scripts, 50.00% okay. 0/25 subtests failed, 100.00% ok +ay. make: *** [test_dynamic] Error 255

        If you load Test::Exception with use_ok you need to do so in a BEGIN block.

        BEGIN { use_ok('Test::Exception'}; }

        will work.


        There are ten types of people: those that understand binary and those that don't.
Re: testing a croak
by BrowserUk (Pope) on Jan 19, 2006 at 05:56 UTC

    Use block eval

    Perl> sub thatDies{ die "Kamakazi\n"; };; Perl> print "Test failed with $@\n" unless eval{ thatDies() };; Test failed with Kamakazi

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      A i see what you mean now by 'testing a croak without die'.
      BrowserUk is right, but i do not like it, for 2 reasons.

      1. I don't like eval.
      Eval creates major security issues if improper used. (and that happens fast). But you're using it for testing, so that won't probably stop you here.
      2. I don't like die
      A script that dies with an error is not my kind of taste. I'd better like to use carp or cluck, and give a warning to the user, but definately not die. (Especially for webbased applications, where they give nasty server-errors)

      *Update* I really don't understand the 'big' discussion that comes up now. I never stated that i BrowserUk was wrong, i said he is right.
      I only stated that i (me myself and i), don't like it, that is not stating that i never use it, or that it should not be used at all.
      I gave 2 reasons (you can agree with or not) why, and IMHO, correct reasons.
      I mainly work in web applications, most of the time a simple warn is enough to create the proper logs i need.
      Next, the use of eval can be dangerous, that's what i point out, not that it allways is, and yes i use eval as well.

      Next, i NEVER EVER stated that my programs are perfect (in fact, they're far from perfect, like most programs are).

      I've got a slight feeling here that there is a bit overreacting here on something that was stated as my own opinion.
      "We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise." - Larry Wall.
        Eval creates major security issues if improper used.

        Wrong. That problem only exists with the string form of eval, not the block form shown, which is the standard Perl equivalent of the try()/catch() pairing found in other languages. Ie. it is the proper way to do this.

        2. I don't like die

        Your prerogative, but it is a standard language facility and deciding you don't like it is arbitrary. Also, remember that not all Perl programs are "web applications".


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
        I don't like die

        /me too. In fact my programs are perfect and never die. Being such a perfect programmer, not only the OS and environment and filesystem they run on are also perfect and never cause failures, etc. but even the users of my programs are perfect (the most prominent one being myself - so that's already a guaranteee!) and never make errors like supplying inexistent files, etc.

        Seriously, web development is not the whole world. die is a perfectly valid and handy language feature - indeed for complex applications, possibly running a GUI, it is sensible to adopt other ways round other than dieing, like warning the user and asking for more input. But for a script that expects a filename on the cmd line to parse, I can't see a more intelligent option than to die, if the file does not exist, for example.

Re: testing a croak
by jbrugger (Parson) on Jan 19, 2006 at 05:44 UTC
    As from the docs on cpan:
    carp - warn of errors (from perspective of caller) cluck - warn of errors with stack backtrace (not exported by default) croak - die of errors (from perspective of caller) confess - die of errors with stack backtrace shortmess - return the message that carp and croak produce longmess - return the message that cluck and confess produce
    "We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise." - Larry Wall.
Re: testing a croak
by vennirajan (Friar) on Jan 19, 2006 at 06:01 UTC
    Hi,

         You can go for the Carp modules. This module has more useful routines which will help a programmer to debug his/her code. Most of the functions looks similar. But they will differ when you go for the OOPS approach. For example,  carp and  cluck functions in this module looks similar when you use them inside the script files (.pl files). But whereas, if you put them use in OOPS way (object, class functionality) you will feel the difference. The main idea is to understand them clearly try them with both the script way and the OOPS way.



    Regards,
    S.Venni Rajan.
    "A Flair For Excellence."
                    -- BK Systems.
Re: testing a croak
by mojotoad (Monsignor) on Jan 19, 2006 at 09:06 UTC
    I just ++'ed everything in this thread.

    I mean, after all.

    We all croak, don't we? Sooner or later?

    Cheers and begged forgiveness,
    Matt

Re: testing a croak
by Sioln (Sexton) on Jan 19, 2006 at 06:52 UTC
    warn maybe?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://524131]
Approved by planetscape
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (9)
As of 2020-08-10 12:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Which rocket would you take to Mars?










    Results (57 votes). Check out past polls.

    Notices?