Re: Some upcoming changes to Test::Builder
On Mon, Oct 14, 2002 at 09:00:42PM -0400, Michael G Schwern wrote: > 5.8.0's threads are giving me serious headaches. When 5.8.1 comes out I > might drop support for 5.8.0's threads just so I can remove a large volume > of work-around code. Leaving support for 5.005 threads in? I'm confused. Or do you mean dropping all automatic threading support? In which case, how does one test threaded code? [not that I've written any] Will there be an explicit thread testing module? Nicholas Clark
Testing failure in the core
Recently I reported a bug which caused perl to segv. http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-10/msg00346.html I thought the solution might be more complex than it turned out to be, and so I included a patch to the test suite to add a TODO test using fresh_perl_is(). Rafael was quite rightly concerned about this. When the bug is fixed we don't want unneeded fresh_perl_is() tests lying around. What is the correct solution here? I was planning to submit another patch when the fix was done. I suppose the passing TODO test would be a reminder to do something. Is this the best way to handle this, or have I missed something? In this case, Rafael fixed the bug and added passing tests, so there was no problem, but in general what is the solution? Now I've asked the same question three times I'll wait for enlightenment :-) -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Testing failure in the core
Paul Johnson <[EMAIL PROTECTED]> wrote: > I thought the solution might be more complex than it turned out to be, > and so I included a patch to the test suite to add a TODO test using > fresh_perl_is(). > > Rafael was quite rightly concerned about this. When the bug is fixed we > don't want unneeded fresh_perl_is() tests lying around. What is the > correct solution here? I was planning to submit another patch when the > fix was done. I suppose the passing TODO test would be a reminder to do > something. In fact I was already thinking about a fix. That's why I didn't add a TODO test that was to be removed. > Is this the best way to handle this, or have I missed something? I think TODO fresh_perl_is() tests are fine, but once the TODO test passes, forking another interpreter isn't worth the pain. And the test should check the correctness of output, not the sole fact that it doesn't segfault. (except of course the rare cases where another interpreter is needed.)
Re: Test::Class - comments wanted
On Mon, Oct 14, 2002 at 05:46:38PM -0400, Michael G Schwern wrote:
> The reason I went with no_plan in Test::Inline was that unlike a dedicated
> test script, a T::I test is cobbled together from a series of seperated
> blocks of tests and it's more difficult than usual to count them all and add
> them up. Adds another step to writing more tests.
> Test::Class shares that cobbled together nature, but if it has a way to
> specify them on a per-block basis, that will work without much trouble.
It does, and it's very nice. I like it a lot.
Most of my tests are now of the format:
sub test_foo : Test {
is shift->do_something, 'expected value', "We can foo!";
}
or, sometimes:
sub test_bar : Test(2) {
my $baz = shift->baz(10);
isa_ok $baz, "Foo::Bar";
is $baz->value, 100, "baz gives correct value";
}
This is a really neat way to specify the number of tests per block.
> OTOH, my thinking recently is that the explicit plan has become obsolescent.
> [1] This thinking makes me nervous, so I'm open to someone convincing me
> otherwise.
The biggest gain I see from it is preventing the accidental deletion of
tests.
A good revision control system will also catch that. But that's a whole
nother story.
Tony
Re: Some upcoming changes to Test::Builder
On Tue, Oct 15, 2002 at 10:34:26AM +0100, Nicholas Clark wrote:
> On Mon, Oct 14, 2002 at 09:00:42PM -0400, Michael G Schwern wrote:
> > 5.8.0's threads are giving me serious headaches. When 5.8.1 comes out I
> > might drop support for 5.8.0's threads just so I can remove a large volume
> > of work-around code.
>
> Leaving support for 5.005 threads in? I'm confused.
Test::Builder has never supported 5.005 threads. At least, I haven't done
anything special to make it work.
> Or do you mean dropping all automatic threading support?
What I mean is in order to make Test::Builder work with 5.8.0's ithreads I
had to hack around a whole lot of bugs and write some really awful code.
Most of it having to do with automatic array/hash extensions not being
shared. For example:
# 5.8.0 threads bug. Shared arrays will not be auto-extended
# by a slice. Worse, we have to fill in every entry else
# we'll get an "Invalid value for shared scalar" error
for my $idx ($#Test_Results..$Expected_Tests-1) {
my %empty_result = ();
share(%empty_result);
$Test_Results[$idx] = \%empty_result
unless defined $Test_Results[$idx];
}
That whole block is just a work around for a 5.8.0 ithreads bug. There's
more like it to make Test::Builder work transparently with ithreads. Here's
another:
my %result;
share(%result);
%result = (
'ok' => 1,
actual_ok => 1,
name => '',
type => 'skip',
reason=> $why,
);
$Test_Results[$Curr_Test-1] = \%result;
which was originally written:
$Test_Results[$Curr_Test-1] = {
'ok' => 1,
actual_ok => 1,
name => '',
type => 'skip',
reason=> $why,
};
and could not be written:
$Test_Results[$Curr_Test-1] = &share {
'ok' => 1,
actual_ok => 1,
name => '',
type => 'skip',
reason=> $why,
};
because threads::shared::share() is broken when threads are disabled.
Really irritating stuff. Every release since 0.45 has added more ithread
work arounds.
So when 5.8.1 comes out and ithreads work better I plan on dropping support
for 5.8.0's still broken ithreads like a hot potato so I can remove all that
hackery. 5.8.1's less buggy ithreads will be supported, hopefully with a
minimum of hackery. Users will simply have to upgrade, which they really
should do anyway if they're using threads.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
I'm spanking my yacht.
Re: Test::Class - comments wanted
On Sun, Oct 13, 2002 at 04:01:10PM -0700, David Wheeler wrote: > On Sunday, October 13, 2002, at 10:05 AM, Tony Bowden wrote: > > >> Makes it simpler for people who prefer the 'no_plan' style of > >> testing > > > >Maybe this is what I just don't get. I'm not one of those people, so I > >don't really understand why people might prefer it. Especially here > >where there's such a natural way to specify them, and you're only > >counting them per method, rather than over the entire test. > > I have to agree with Tony. I think it's important to explicitly > indicate the number of tests that a given method runs, and to be > explicit about saying when you're not sure how many tests there will > be. In that regard, I like the current design better, although I would > have no complaint if you decided to change the string "no_plan" to > something else. Me too. In that I'd not like "no plan" to be the default. I'd like it to be necessary to explicitly choose no plan. I'm not sure if it is helpful (or even a good interface) but it's possible to count the number of arguments in @_, and thereby distinguish between no arguments and 1 undef argument. It's just that saying "pass a literal undef for no plan" is about as clear as "no_plan". Empty string is probably clearer, and quite easy to test for (with length, after a defined || croak test) Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
