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

Esteemed monks,

At $work I'm trying to write some tests for this Perl application we have. Thing is, the only perl I have is 5.8.5, running on an old Solaris box. I have absolutely no control over what is installed there. Neither do I have any leverage to request that the installed perl and/or modules be updated, especially for a maintenance task ("no, we can't sell unit tests to the client").

So as I'm writing tests, I try to BAIL_OUT on a database handle not being opened, and it turns out this is an older Test::More which doesn't have BAIL_OUT implemented yet.

My question is thus: How did you BAIL_OUT in the olden times when there was no BAIL_OUT?

Of course I don't *absolutely* need to BAIL_OUT here, but if I can't connect to the database, most all of the following tests are going to die a horrible death anyway, and I'd rather have the reason clearly visible in my test output than having to hunt for the first test that doesn't pass.

Replies are listed 'Best First'.
Re: BAIL_OUT with older Test::More
by toolic (Bishop) on Feb 15, 2011 at 13:46 UTC
    You could download and install a newer version of Test::More which has BAIL_OUT and use that instead. Place the updated module in a directory which you can control, then point to it with lib or PERL5LIB.

      Unless your managers/IT department are absolutely opposed to your downloading modules into your own home directory, this node: Yes, even you can use CPAN discusses how you to do what toolic is suggesting.

        Well, I was thinking of this as well, but with the red tape and all I still don't know if I can introduce foreign code like this. It depends on whether the management will OK this or not, and whether the IT people feel paranoid that day...

        In the meantime I'm doing without BAIL_OUT. In the eventuality that I can't use a more modern Test::More at all, what do you suggest?

Re: BAIL_OUT with older Test::More
by Khen1950fx (Canon) on Feb 15, 2011 at 15:03 UTC
    BAIL_OUT() used to be BAILOUT(). The current Test::Builder has BAIL_OUT(), so I think that you could use BAILOUT() instead. According to this thread from Google groups perl.perl6.internals, BAILOUT can be used and remains as an undocumented and deprecated method.

      Yes, thank you!

      I'd stumbled across that thread, wasn't sure it would work, but it does (with weird output, though):

      Test::Builder->BAILOUT("oh no"); # outputs: # tests_sante_reporting/02-infocentre-sanity.......NOK 1FAILED--Furthe +r testing stopped: oh no # # Looks like you planned 2 tests but only ran 1. Test::Builder->BAILOUT("oh no\n"); # outputs (yes, like this): # # tests_sante_reporting/02-infocentre-sanity.......NOK 1# Looks like + you planned 2 tests but only ran 1. # FAILED--Further testing stopped: oh no Test::Builder->BAILOUT("\noh no\n"); # outputs (yes, also like this): # tests_sante_reporting/02-infocentre-sanity.......NOK 1# Looks like y +ou planned 2 tests but only ran 1. # FAILED--Further testing stopped.

      I think I'm going to go with number 1.

        I tried it like this, and it works. BAILOUT is doable. I designed it to have failing tests just to see what happens...
        #!/usr/bin/perl use strict; use warnings; use Test::Builder; use Test::More; BEGIN { use_ok( 'Test::Simple ' ); } my $Exit_Code; BEGIN { *CORE::GLOBAL::exit = sub { $Exit_Code = shift; }; } my $output; my $TB = Test::More->builder; $TB->output(\$output); my $Test = Test::Builder->create; $Test->level(0); $Test->plan(tests => 3); plan tests => 1; $Test->is_eq( $output, <<'OUT' ); 1..3 Bail out! Sayonara! OUT if ($Test) { $Test->is_eq( $Exit_Code, 255 ); $Test->ok( $Test->can("BAILOUT"), "Backwards compat" ); } else { BAILOUT(print "Sayonara!\n"); }
Re: BAIL_OUT with older Test::More
by ELISHEVA (Prior) on Feb 15, 2011 at 13:42 UTC
    die "FAILED--Further testing stopped: ".$reason ?

      Yes, I should have mentioned I tried die()-ing. The tests for this .t end but the rest of the .t try to run; what I'd want is for the harness to realize that something's gone wrong enough that you don't need to run the rest of the tests.