http://qs321.pair.com?node_id=208426

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

Hi,
I'm writing a module to verify data values. The objects are esentially factories which write subroutines to validate data items.

As part of their construction these objects can be fed arrays or subroutine references. The relevant set routines check to see if you've fed them the right type of thing - this is done using ref :-

sub _ref_check {
my ($test,$should_be) = @_;
my $ref = ref($test);

unless ($ref eq $should_be) {
    if (length($ref) > 0) {
        carp ("\n>> $test isn't a reference to a $should_be, but rathe
+r a reference to a ".$ref."\n")
        } else {
        carp ("\n>> $test isn't an array reference at all, but a SCALA
+R\n")
        }# if (defined($refref))
        return 0;
    } # unless ($ref eq $should_be)
return 1;
} #End of subrotuine _ref_check

[download]

This works fine, and I'm happy with it, but in my test scripts I have chosen to test that I can't feed improper things to the set routines. As you can see the error reports from carp in _ref_check() turn up in the test output.

t\01-sanity.....................ok
t\02-simple.....................ok 16/0
>> 4 isn't an array reference at all, but a SCALAR
# # Won't accept scalar values
>> HASH(0x1dec550) isn't a reference to an array, but rather a referen
+ce to a HASH
# # Won't accept hash values
t\02-simple.....................ok
t\03-transform..................ok 3/0
>> ARRAY(0x1c0ba88) isn't a reference to a subroutine , but rather a r
+eference to an ARRAY
t\03-transform..................ok 5/0
>> 4 isn't an array reference at all, but a SCALAR
t\03-transform..................ok 7/0
>> HASH(0x1ab5430) isn't a reference to an array, but rather a referen
+ce to a HAS
t\03-transform..................ok
[snip]
All tests successful.
Files=9, Tests=101,  1 wallclock secs ( 0.00 cusr +  0.00 csys =  0.00
+ CPU)

[download]

So what I would like is style advice - is it appropriate/accepatable for tests to output something besides

t\01-sanity.....................ok

[download]

In any event can I turn off carp, or otherwise lose diagnostic output while running tests?

--
Anthony Staines

P.S. If you're really curious the module will be on my scratchpad for a while, but it's not really ready for the real world...

Replies are listed 'Best First'.
Re: Silencing warnings when testing
by Ovid (Cardinal) on Oct 28, 2002 at 02:07 UTC

    I typically use typeglobs to override the sub and capture the arguments. Then, you can test whether or not carp was called and if it received the correct arguments. Below is a test script.

    #!/usr/bin/perl -w
use strict;
package Foo;
use Carp;

sub bar {
    carp "This is a test";
}

package main;
use Test::More 'no_plan';
use constant MODULE => 'Foo';

{
  my $carp;
  local *Foo::carp = sub { $carp = join '', @_ };
  can_ok( MODULE, 'bar' );
  Foo::bar();
  ok( $carp, 'Calling Foo::bar() should call carp()' );
  is( $carp, 'This is a test', '... with the correct error message' );
}

    [download]

    Just make sure that you localize the typeglob. This ensures that subsequent calls to carp that you forgot to trap will still spit out error messages.

    Cheers,
    Ovid

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[reply]
[d/l]
Re: Silencing warnings when testing
by chromatic (Archbishop) on Oct 28, 2002 at 04:24 UTC

    If you use Test::More, you can use the diag() function to print diagnostic or debugging information. Test::Harness will suppress it when running tests normally. You can run the test by hand or with the verbose flag and see them.

    If you are using Test::More, you can also use Test::Exception and Test::Warning to test for death and warnings. I've had good results with them.

[reply]
[d/l]
(tye)Re: Silencing warnings when testing
by tye (Sage) on Oct 28, 2002 at 03:24 UTC

    The test harnesses don't complain about lines that start with "#" so you can do:    local( $SIG{__WARN__} )= sub { warn "# ",@_ }; to keep the warnings but prevent them from looking unintentional.

            - tye (but don't call me "# Tye")
[reply]
[d/l]
Re: Silencing warnings when testing
by grantm (Parson) on Oct 28, 2002 at 02:16 UTC

    I have very similar logic in a number of my test scripts. I use an eval block and check that the message in $@ matches what I was expecting. That won't work directly for you since your code uses 'carp' where mine uses 'croak'.

    If one of your methods is passed an invalid argument, is there any point carrying on? Rather than carp and return 0, why not just croak?

    Coming back to your original question though, you could capture warning messages like this:

      our $last_warning = '';
  $SIG{__WARN__} = sub { $last_warning = shift; }

  ... code that generates warning ...
  ... code that checks contents of $last_warning ...

    [download]
[reply]
[d/l]

Back to Seekers of Perl Wisdom