Re: [perl #15479] perl 5.8.0 segfault

2002-07-31 Thread Robert Spier

>> And where did the p5p FAQ get to?
>MJD said he was taking it off his website... or do you mean the serious one?

Do you mean this?

http://simon-cozens.org/writings/p5p-faq

If someone wants to become a new champion for it, we can keep it on
http://dev.perl.org/perl5.  (Another way to enable that would be to
merge it into the perl5 sources, and then the website can check it out
periodically.)

-R




Re: Help spreading Test

2002-07-31 Thread David Wheeler

On Wednesday, July 31, 2002, at 10:15  PM, Johan Vromans wrote:

> My hesitation in doing this is that the module does not need Test::*
> for its operation, just for the IVP.

Given what the Test::* modules are for, I think that this is common. And 
since they're small and won't waste much in the way of resources once they'
ve been installed, I personally think it's no big deal to install them.

David

--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/  Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]




Re: Help spreading Test

2002-07-31 Thread Johan Vromans

Michael G Schwern <[EMAIL PROTECTED]> writes:

> It's probably easier to just make it a normal prerequisite.

My hesitation in doing this is that the module does not need Test::*
for its operation, just for the IVP. 

But I tend to agree that making any special provisions for this
purpose is probably not worth it. 

-- Johan





Slides from OSCON

2002-07-31 Thread Michael G Schwern

Figured folks might be interested in slides from talks at OSCON:

http://www.pobox.com/~schwern/talks/How_To_Be_Lazy_Redux/
http://www.pobox.com/~schwern/talks/Test_Tutorial/
http://www.pobox.com/~schwern/talks/Writing_A_Test_Library/

-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance  <[EMAIL PROTECTED]> Kwalitee Is Job One
Home of da bomb



Re: Help spreading Test

2002-07-31 Thread Michael G Schwern

On Sat, Jul 27, 2002 at 09:55:38AM -0700, chromatic wrote:
> > One of the problems I have with using Test::Builder is that I want to
> > distribute packages to systems that do not (necessarily) have a decent version
> > of Test::* installed. Now it is easy to include a copy of a suitable version
> > of Test::Builder with the package (provided it is not too big). Would it be a
> > good idea to add a provision to Test::Builder that can be called, from the
> > Makefile.PL, to display a message like this:
> > 
> >   The verificiation tests for this package require the Test::Builder package
> >   of at least version X.Y. You do not seem to have this installed. I have
> >   included a copy of Test::Builder in this distribution that I can use for
> >   testing. Do you want me to install this version of Test::Builder as well?
> > 
> > This would help spreading the good stuff.

I'm not sure of the context here, but at this point of complexity it's
probably easier to just make it a normal prerequisite.

Why?

o If you're not using a CPAN shell, every module installation involving any
  prerequisites is going to be a chore.  Adding one more to that pile isn't
  really going to make much difference.

o At least for Test::Simple/More/Builder, so many modules already have
  dependencies on them (including CPAN, CPANPLUS and Storable) that you
  probably already have them installed.  There's a slide in the
  Test::Tutorial talk with a list current as of a month ago.

o If you don't already have them installed, you only need to do it once.


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance  <[EMAIL PROTECTED]> Kwalitee Is Job One
5. It is always possible to aglutenate multiple separate problems
   into a single complex interdependent solution. In most cases
   this is a bad idea.
-- RFC 1925



Re: [PATCH Test::Builder] Add diagnostic messages to details

2002-07-31 Thread Michael G Schwern

On Sat, Jul 27, 2002 at 09:44:03AM -0700, chromatic wrote:
> This patch captures messages sent through diag() and stores them in the
> diagnostic array.  Now all of the information the tests generate is available
> for later inspection.

Dude, where's my patch?


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance  <[EMAIL PROTECTED]> Kwalitee Is Job One
Me? A robot? That's rediculous! For one thing, that doesn't compute at all!



Re: [perl #15479] perl 5.8.0 segfault

2002-07-31 Thread chromatic

On Wed, 31 Jul 2002 04:30:12 -0700, Nicholas Clark wrote:

> On Wed, Jul 31, 2002 at 01:20:25PM +0200, Rafael Garcia-Suarez wrote:
 
>> Wasn't there a .t file to run separate perl interpreters and test for core
>> dumps ?
 
> I keep forgetting that I need to remember to ask this. Is there a FAQ for
> regression test writing? Well, an guide to "so I want to write a regression
> test, explaining how to do it, how perl5's tests are structured to reduce
> interdependencies, use Test::More; when Test::More is not appropriate.."

Schwern and I talked about this last week.  pod/perltest.pod was a likely
candidate, though Perl QA have been working on Test::FAQ on the Wiki.  There's
also Test::Tutorial.  It's in the core.
 
> And where did the p5p FAQ get to?

MJD said he was taking it off his website... or do you mean the serious one?

No idea.

-- c



RFC: Test::ManyParams

2002-07-31 Thread Janek Schleicher

Hello!

I'm writing in nearly every Perl test script a method
all_ok, all_dies_ok or all_throws_ok new.

That's why I want to write a module specialled in 
testing one feature for many parameters.
As I'm very interested in your opinion about,
I'll describe some planned features in the following.

I want to name it Test::ManyParams
but I'm not a very creative man,
perhaps anybody has even a better idea :-)


E.g. let's assume, I would rewrite an Image module.

One of the first tests is to create a new one,
and I would like to be sure that it is empty,
what I prefer to write as:

my $img = Image->new(width => $width, height => $height);
all_ok {$img->color(@_) == 0}
   [ [0 .. $height-1], [0 .. $width-1] ],
   "Image should be empty after initialization";

what would print in the case of a failure something like
not ok XX - 
# Parameters (0, 3)

Another example is to test for wrong paramters,
where I suppose the subroutine to die.

use constant WRONG_PARAMETERS => (
   -1,   # can't scale negative
   "double",   # well, a feature of the future, let's say 2.0 at the time
   undef,
   [],# no array ref
   {},# no hash ref
   "2x",  # still write it as 2.0
);
all_dies_ok {$img->scale($_)}
[WRONG_PARAMETERS],
"should die with wrong parameters"
   

Perhaps, I'm too paranoid in these examples,
but I'm sure, it would be useful to have a module
specialled in testing one feature for many parameters.


Thinking in general,
there could be also some other features included.
Let's think we'd like to test the creation of big pictures,
perhaps 5_000 x 5_000.
It could take a while to make a test for all pixels,
but we also would like to test some of them (randomly choosen),
to avoid systematic error.
That could be nice written as:

$img->fill(BLUE);   # my transformation to test
most_ok {$img->color(@_) == BLUE}
[ [0 .. 5_000], [0 .. 5_000] ] => 1_000,
"after filling with blue it should be blue - hick";

Well, I'm not sure about the name most_ok,
perhaps you have a better idea.
The third parameter in the above example
specifies that 1000 tests should be done.
I thought that also specification like
"500 + bounds"   # to test 500 ones + all corners
"5%"
"10 seconds" # to test 10 seconds long
...


Further, convinient methods like
all_like,
all_can, 
all_isa,
all_warn,
could be useful, too.


Greetings,
Janek




Re: [PATCH Test::Builder] Add diagnostic messages to details

2002-07-31 Thread chromatic

On Wednesday 31 July 2002 12:39, Michael G Schwern wrote:

> > This patch captures messages sent through diag() and stores them in the
> > diagnostic array.  Now all of the information the tests generate is
> > available for later inspection.

> Dude, where's my patch?

Did I completely miss it?  Let's try this instead.

-- c

diff -ur Test-Simple-0.46~/lib/Test/Builder.pm Test-Simple-0.46/lib/Test/Builder.pm
--- Test-Simple-0.46~/lib/Test/Builder.pm	Sat Jul 20 17:16:02 2002
+++ Test-Simple-0.46/lib/Test/Builder.pm	Sat Jul 27 09:39:22 2002
@@ -296,7 +296,7 @@
 my $todo = $self->todo($pack);
 
 my $out;
-my $result = {};
+my $result = $Test_Results[$Curr_Test-1] ||= {};
 
 unless( $test ) {
 $out .= "not ";
@@ -329,7 +329,6 @@
 $result->{type}   = '';
 }
 
-$Test_Results[$Curr_Test-1] = $result;
 $out .= "\n";
 
 $self->_print($out);
@@ -658,13 +657,8 @@
 lock($Curr_Test);
 $Curr_Test++;
 
-$Test_Results[$Curr_Test-1] = {
-'ok'  => 1,
-actual_ok => 1,
-name  => '',
-type  => 'skip',
-reason=> $why,
-};
+my $results = $Test_Results[$Curr_Test-1] ||= {};
+@$results{qw( ok actual_ok name type reason )} = ( 1, 1, '', 'skip', $why );
 
 my $out = "ok";
 $out   .= " $Curr_Test" if $self->use_numbers;
@@ -700,13 +694,9 @@
 lock($Curr_Test);
 $Curr_Test++;
 
-$Test_Results[$Curr_Test-1] = {
-'ok'  => 1,
-actual_ok => 0,
-name  => '',
-type  => 'todo_skip',
-reason=> $why,
-};
+my $results = $Test_Results[$Curr_Test-1] ||= {};
+@$results{qw( ok actual_ok name type reason )} =
+( 1, 0, '', 'todo_skip', $why );
 
 my $out = "not ok";
 $out   .= " $Curr_Test" if $self->use_numbers;
@@ -897,6 +887,10 @@
 my $fh = $self->todo ? $self->todo_output : $self->failure_output;
 local($\, $", $,) = (undef, ' ', '');
 print $fh @msgs;
+my $prev_test = $Curr_Test - 1;
+$prev_test = 0 if $prev_test < 0;
+$Test_Results[ $prev_test ]{diag} ||= [];
+push @{ $Test_Results[ $prev_test ]{diag} }, @msgs;
 
 return 0;
 }
@@ -1350,7 +1344,7 @@
 
 In perl 5.8.0 and later, Test::Builder is thread-safe.  The test
 number is shared amongst all threads.  This means if one thread sets
-the test number using current_test() they will all be effected.
+the test number using current_test() they will all be affected.
 
 =head1 EXAMPLES
 
diff -ur Test-Simple-0.46~/t/details.t Test-Simple-0.46/t/details.t
--- Test-Simple-0.46~/t/details.t	Sat Jul 20 17:08:36 2002
+++ Test-Simple-0.46/t/details.t	Sat Jul 27 08:45:45 2002
@@ -47,6 +47,7 @@
 
 TODO: {
 local $TODO = 'i need a todo';
+#line 50
 $Test->ok( 0, 'a test to todo!' );
 
 push @Expected_Details, { 'ok'   => 1,
@@ -54,6 +55,7 @@
   name   => 'a test to todo!',
   type   => 'todo',
   reason => 'i need a todo',
+			  diag   => [ "# Failed (TODO) test ($0 at line 50)\n" ],
 };
 
 $Test->todo_skip( 'i need both' );
@@ -76,15 +78,19 @@
   reason=> '',
 };
 
+
 $Test->current_test(6);
+
 print "ok 6 - current_test incremented\n";
 push @Expected_Details, { 'ok'  => 1,
   actual_ok => undef,
   name  => undef,
   type  => 'unknown',
   reason=> 'incrementing test number',
+		  diag  => [ '# Added', '# diagnostics', "\n" ],
 };
 
+$Test->diag(qw( Added diagnostics ));
 my @details = $Test->details();
 $Test->is_num( scalar @details, 6,
 'details() should return a list of all test details');



Re: [perl #15479] perl 5.8.0 segfault

2002-07-31 Thread Nicholas Clark

On Wed, Jul 31, 2002 at 01:20:25PM +0200, Rafael Garcia-Suarez wrote:

> Wasn't there a .t file to run separate perl interpreters
> and test for core dumps ?

I keep forgetting that I need to remember to ask this. Is there a FAQ
for regression test writing? Well, an guide to "so I want to write a
regression test, explaining how to do it, how perl5's tests are structured
to reduce interdependencies, use Test::More; when Test::More is not
appropriate.."

And where did the p5p FAQ get to?

Nicholas Clark