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

Hi All,
  Having nearly finished my latest software update, I've decided to write a comprehensive test suite to ensure that everything is working properly and making it easy to see if future changes have broken things. Why I didn't do this in the first place is beyond me...
  I've been reading through my 'Perl Testing' book (many thanks to chromatic and Ian) and putting some tests together in the usual t/*.t files. I don't have a lot of experience with this but it all seems pretty straight forward and the book is a great help.
  The problem I've hit is this. My software uses CGI, and is running on many different machines across the net. I want users to be able to run some or all of the tests at any time through the browser based admin area.
I put together a quick script that ran the tests with a simple do and tested it on my local IIS/Perl8 setup.
do ('t/00modules.t');
When I ran the cgi in my browser I got:-
1..2 ok 1 - use module; ok 2 - DateNext() should increment the date by 1 day doneFree to wrong pool 222c90 not 40c01b1 during global destruction.
The CPU hits 100% for a few seconds then I get a popup saying:-
Perl Command Line Interpreter has encountered a problem and needs to c +lose. We are sorry for the inconvenience.
Seems this is causing a perl to panic. If I run the test through the command line it works fine.

Now I know I could just use system or `` to call the test with perl, but on some of the installations (especially the Win2003/IIS/Perl8 ones) the cgi's done have permission to run commands in that way.

So I've hit a bit of a brick wall as I have no idea why using do () is causing a panic and what I can do to fix it.

I hoping a monk with more testing experience can help me.


Lyle

Many thanks to YourMother for providing a solution:-
use Test::Harness::Straps; my $strap = new Test::Harness::Straps; my %results = $strap->analyze_file( 't/00modules.t' ); use Data::Dumper; print Data::Dumper->Dump([\%results]);

Replies are listed 'Best First'.
Re: Running test filese from a cgi
by Your Mother (Archbishop) on Apr 26, 2008 at 16:47 UTC

    I'd say don't use do. If you've got the test notebook you can find the sample for a smoke test on p57, something like this (incomplete code)-

    my $strap = Test::Harness::Straps->new(); for my $test ( <path/to/tests/*.t> ) { # warn/debug "Running test: $test\n"; my %result = $strap->analyze_file( $test ); next if $result{passing}; # Build report on failing results here # to present in an Ajax'd div or something. }

    You might accidentally fix it by not using do and you should at least track the problem down to a single test otherwise.

    Update: s/frame/div/; I did not mean a literal HTML frame.

      aghhhh... finally I fully understand what all those smoke test reports on p5p are about. Wackad :)
      This looks like the solution. I'll update my post if it works. Thank you.
Re: Running test filese from a cgi
by stiller (Friar) on Apr 26, 2008 at 16:32 UTC
    I'm not sure exactly what is stopping you here, but I'd suggest another organization of the job.

    Let your web-app create a file. Let a cron (or at) -job start every, say, 20 second to see if this file exist. If it exist, read it in and remove it. The file contains instructions on what to test. The cronjob now runs the tests and make the results available for the admin app to pick up and present to the user.