On Sat, Dec 15, 2001 at 11:46:29PM +0000, Nicholas Clark wrote: > On Sat, Dec 15, 2001 at 05:59:22PM -0500, Michael G Schwern wrote: > > On Sat, Dec 15, 2001 at 11:48:29PM +0100, Tels wrote: > > > Te"One day Math::Big* will have more tests than Perl;)"ls > > > > One day Perl will have more tests than Bit::Vector. 67255 at last count. > > Ilya chose not to attempt that for 5.6, by make op/numconvert.t only report > 1 ok (or not) for a cluster of 15 numbers passed through the same conversions. > We could always change op/numconvert.t to report 15 times as many tests > (about another 20,000 I think)
Finer granularity is often better than lumping them all together, makes it easier to figure out which one is failing. numconvert.t gets around this by the way it reports its failures with the big blat of diagnostics. In the interests of myself never wanting to touch numconvert.t for fear of it getting angry, digitizing and being thrown onto the game grid, do whatever you feel is best with it. :) > But that's cheating, isn't it? It may be useless, but its fun to see who can pee the farthest. ;) > More on topic - I like Test::More. > I like test.pl in the core. > But I fear that we aren't bootstrapping our tests carefully enough. > In that I'm pretty sure we shouldn't be using Test::More until we're > sure we've tested all the ops Already done. By the Treaty Of t/, Test::More's domain is limited to ext/ and lib/. And Andy's fears about its widespread use leading to a cascade failure has come true, as it collapsed on djgpp and took a good chunk of lib/ with it. Still working out my djgpp environment to look at that. > and we shouldn't be using test.pl until we've tested all the ops it > uses (and be careful to limit the ops and the complexity of ops it > uses) Sort of. t/test.pl is written to avoid the more twitchy things which Test::More plays with (like duping filehandles) and does keep the "peculiar style" axiom in mind. However, trying to limit the use of t/test.pl to only things which it doesn't use at all can get complicated and somewhat tedious as it leaves us without a test library for good chunk of the ops. It also gets into the tricky problem of finely ordering the tests to they run in some sort of dependency order, and I really don't want to get into that right now. t/test.pl using, say, caller() and it also being used in t/op/caller.t (which, umm... I can't seem to find) is fine as long as t/test.pl limits itself to the basic, rock-solid functionality of caller. If t/test.pl started using things like the more obscure bits of caller() that's a bit more likely to break (say, the $hints) I'd be worried. > TEST starts: > > # This is written in a peculiar style, since we're trying to avoid > # most of the constructs we'll be testing for. Which is sort of a white lie these days, but its still quite a bit simpler than Test::Harness. -- Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One It sure is fun masturbating. http://www.unamerican.com/
