Re: [perl #15479] perl 5.8.0 segfault
On Wed, Jul 31, 2002 at 12:30:12PM +0100, 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 ? We're dissolving that. Use fresh_perl_is() and fresh_perl_like() from t/test.pl and place the test in the appropriate group. So somewhere with other filehandle tests. > 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.." Porting/patching.pod About the only thing that's missing is docs for t/test.pl. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One We have returned to claim the pyramids.
Re: [perl #15479] perl 5.8.0 segfault
Michael G Schwern wrote: >>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.." > > > Porting/patching.pod So we have patching.pod, perlhack.pod (which is also at http://dev.perl.org/perl5/docs/perlhack.html ), pumpkin.pod (which has also useful information for non-pumpkings)... > About the only thing that's missing is docs for t/test.pl. I added a short note about the existence of t/test.pl in t/README recently. Hey, that's another document ;-)
Re: RFC: Test::ManyParams
> On Wed, 31 Jul 2002 21:52:17 +0200, Janek Schleicher <[EMAIL PROTECTED]> said: JS> [..snip..] JS> Thinking in general, JS> there could be also some other features included. JS> Let's think we'd like to test the creation of big pictures, JS> perhaps 5_000 x 5_000. JS> It could take a while to make a test for all pixels, JS> but we also would like to test some of them (randomly choosen), JS> to avoid systematic error. Test results should be easily reproducible. I don't think having randomly choosen tests is good idea. Say you have written CPAN module. One day you get email from user with bug report about 'make test' being failing. You ask him to rerun test with TEST_VERBOSE=1 to see in details why it failing but surprise - it doesn't fail anymore. Have fun finding what's get wrong. JS> [..snip..] -- Ilya Martynov (http://martynov.org/)
Re: RFC: Test::ManyParams
Ilya Martynov wrote at Fri, 02 Aug 2002 07:42:44 +0200:
>> On Wed, 31 Jul 2002 21:52:17 +0200, Janek Schleicher <[EMAIL PROTECTED]> said:
>
> JS> [..snip..]
>
> JS> Thinking in general,
> JS> there could be also some other features included.
> JS> Let's think we'd like to test the creation of big pictures,
> JS> perhaps 5_000 x 5_000.
> JS> It could take a while to make a test for all pixels,
> JS> but we also would like to test some of them (randomly choosen),
> JS> to avoid systematic error.
>
> Test results should be easily reproducible. I don't think having
> randomly choosen tests is good idea.
srand could be our friend.
> Say you have written CPAN module. One day you get email from user
> with bug report about 'make test' being failing. You ask him to rerun
> test with TEST_VERBOSE=1 to see in details why it failing but surprise
> - it doesn't fail anymore. Have fun finding what's get wrong.
Well, failing a test this way will produce a short description of the parameters
via diag, so it's also seen with 'make test'.
However, it's not important for me that the parameters are really randomly choosen -
allthough I still would prefer to have some before I release a module -
but I'd like to write tests to avoid systematic mistakes,
while it would need too long to test all scenarios.
But perhaps, I should better write a function to extract them,
so I could write something like
all_ok {$img->color(@_) == 0}
params( [ [0 .. 50_000], [0 .. 50_000] ], "1000 + bounds" )
"all pixels I looked for in the big image are black";
and I could guarantee,
that params( ... )
chooses the same params for the user and for me.
Greetings,
Janek
