lib.t (was Re: Untested modules update: There's more than we thought)
On Fri, Dec 14, 2001 at 05:57:06PM -0500, Michael G Schwern wrote: > > #how about use's? > > is( > > `perl "-Mlib=stuff -MYup" -e "print 'ok'"`, > > 'ok', > > 'affects use' > > ); > > A simple way to trick 'use' is to clear the entry from %INC and then > eval "use Yup". I just thought of a better way. Since all we're testing is that lib.pm does the right things to @INC, we can presume that if one of require(), do() or use() works, the rest will work. So for most everything, set Yup.pm to return some unique value and then just use do() for most everything. That way it'll work multiple times in the same program without eval or `` trickery. print YUP <http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One I was *meant* to mount your donuts.
Re: v0.3 [Was: CPAN Upload: R/RB/RBS/Test-Differences-0.2.tar.gz]
On Sat, Dec 15, 2001 at 02:41:13AM -0500, Barrie Slaymaker wrote: > There's also a test script for the escaping now :). I'd love to test > characters for codepoints > 0xff, but they're borken / unsupported in > all released perls, I think. Broken is such an ugly word. "Experimental" :) 5.6.1's unicode implementation should be usable enough for your purposes. You might want to have a file full of Unicode tests that only runs if you've got a Perl >= 5.6.1 -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Hey, Schwern! THERE IS A HUGE GAZORGANSPLATTEDFARTMONGERING- LIGHTENINGBEASTASAURSOPOD BEHIND YOU! RUN, BEFORE IT GAFLUMMOXES YOUR INNARDLYBITS!
Re: v0.3 [Was: CPAN Upload: R/RB/RBS/Test-Differences-0.2.tar.gz]
On Sat, Dec 15, 2001 at 06:52:40PM +0900, Tatsuhiko Miyagawa wrote: > Again, IMHO we can get the benefit of Test::Differences like this: > > * First, test the code with Test::More::is() > > is $complicated_long_text, $expected; > > * but it fails. > > Test::More's output is too long for me to find what's the > differecne with the two. > > * Then we want the output switch to Text::Diff's one. Why not just use Test::Differences's function in the first place? -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One "You can't set a generic cow." -- Randal Schwartz
Re: v0.3 [Was: CPAN Upload: R/RB/RBS/Test-Differences-0.2.tar.gz]
On Sat, Dec 15, 2001 at 07:54:17PM +0900, Tatsuhiko Miyagawa wrote: > 2) Testing my CPAN module > > I don't like letting go Test::More for it ;) If I understand you, they work together fine. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One I know you get this a lot, but what's an unholy fairy like you doing in a mosque like this?
Re: v0.3 [Was: CPAN Upload: R/RB/RBS/Test-Differences-0.2.tar.gz]
On Sat, Dec 15, 2001 at 10:52:07AM -0700, chromatic wrote: > On Sat, 15 Dec 2001 07:10:33 -0700, Barrie Slaymaker wrote: > > > How about having Test::More use eq_or_diff_data() in is_deeply() if it cane > > eval "use Test::Differences;" and use it's current routine if it can't? That's > > as seamless as you can get. > > Wild idea: > > How about splitting out the error-reporting, with a nice default in > Test::Builder or wherever, using optional modules if possible? > > use Test::More > tests => 100, > report => Test::Differences; The two modules can already work together in the same script. So, if you have Test::Differences, which has superior complex data structure handling, why are you calling is_deeply() in the first place? -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One my mother once said "never eat paste my darling" would that I heeded -- stimps
Good news/bad news about perlcc
The bad news is perlcc is completely shot, and has been since 5.6.1. The bytecode and Perl->C compiler is completely busted and nobody's stepped forward to fix it. The last people to do so was Simon Cozens and tchrist. Simon's busy with Parrot and Tom's gotten a life outside Perl now. Malcolm Beattie, the original author, has also gone to live in the big blue room. The good news is, if its broken and nobody can fix it, we can't do much to test it! :) After throwing some basic perlcc sanity checks into the core, I'm scratching B::Assembler, B::Bytecode, B::C, B::CC and B::Disassembler (can't disassemble something you can't assemble) off the list. The magic number is 28. #B::Assembler [perlcc irreparably broken, can't test] #B::Bytecode[ditto] #B::C [ditto ditto] #B::CC [again] #B::Concise [[EMAIL PROTECTED]] #B::Disassembler[can't disassemble what you can't assemble] #B::Lint[[EMAIL PROTECTED]] #B::Stackobj[[EMAIL PROTECTED]] #B::Xref[[EMAIL PROTECTED]] Byteloader CPAN Dynaloader ExtUtils::MM_NW5 ExtUtils::MM_OS2 ExtUtils::MM_Unix ExtUtils::MM_VMS ExtUtils::MM_Win32 ExtUtils::Install ExtUtils::Installed ExtUtils::Liblist ExtUtils::Mksymlists #lib [Brent Dax] Net::Cmd Net::Domain Net::Ping Net::POP3 O Pod::Functions (no docs!) Pod::Html Pod::InputObjects Pod::Select Pod::Usage re -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Milk is timeless.
is_op -> cmp_ok. is() remains as it is.
Ok, here's what I've decided. The is_ok() thing will be cmp_ok(). Best name I could think of. The current behavior of is() wrt undef, 0 and '' being considered different will remain. I've decided is() is its own thing and the small bit of magical behavior is Good. unlike() and diag() will be added next version. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One "His plagiarism was limited only by this faulty technique." -- Peter Schickele
Re: Untested modules update: There's more than we thought
On Sat, Dec 15, 2001 at 11:46:29PM +, 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/
Re: Untested modules update: There's more than we thought
On Sat, Dec 15, 2001 at 02:19:21PM -0800, Kurt D. Starsinic wrote: > On Dec 15, Dave Rolsky wrote: > > Ok, so that's a bit off the topic of "why use isa_ok()" but I just don't > > see why people seem to object to the use of Test::More in the core Perl > > tests. I can't see how it couldn't help improve the quality of the tests > > while providing a standardized way to do the things that all the tests do > > anyway. > > I, for one, don't object to the use of Test::More in the core Perl > tests. I'm just being responsibly skeptical about the promotion of many > different test harness modules with many different functions. It runs > the risk of _seeming_ like the People in Charge don't know what testing > is for, and of not providing effective guidance to those people writing > their first tests. We have Test::Simple, Test::Tutorial and eventually Test::FAQ for such guidance. Work on those if you're worried about providing effective guidance. Beyond that, I'm not going to cut down my toolbox to only a hammer just because it looks tidy. (And its PERL! Of course you're going to have 25 different types of bevels in the toolbox.) Its also been "discovered" just recently that its now possible to inter-mix several different Test::* modules in the same program, as long as they all use the Test::Builder backend (and Barrie found a way to cheat with Test.pm). http:[EMAIL PROTECTED]/msg01091.html This means its no longer necessary to write monolithic test modules. You can write special purpose modules for special purpose things and combine them as you please. After the next release, which will complete the interface with cmp_ok() (aka. is_op), unlike() and eval_ok(), Test::More's growth is pretty much over. I'll leave the rest to seperate modules. > I also think that we have a real testing problem, which is that it > isn't _trivially_ easy to run a huge test suite (like Alzabo's, or Perl's) > and to find out at the end which tests failed and what their output was. > 3000 lines and 20 minutes later, a message that 3 out of 1 tests > failed is not maximally useful. Greater variety of test functions is not > (IMNSHO) nearly as important as addressing that. Test::More outputs its diagnostics to STDERR, so they appear as you run 'make test'. PERL_DL_NONLAZY=1 /usr/local/bin/perl -Iblib/arch -Iblib/lib -e 'use Test::Harness qw(&runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t t/Module-InfoNOK 3# Failed test (t/Module-Info.t at line 15) # got: 'foo' # expected: 'bar' t/Module-Infook 73/74# Looks like you planned 74 tests but ran 1 extra. t/Module-Infodubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED test 3 Failed 1/74 tests, 98.65% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t/Module-Info.t2 512741 1.35% 3 Failed 1/1 test scripts, 0.00% okay. 0/74 subtests failed, 100.00% okay. Even in the core: $ ./perl TEST ../lib/foo.t t/../lib/foo# Failed test (../lib/foo.t at line 10) # got: 'foo' # expected: 'bar' # Looks like you failed 1 tests of 1. FAILED at test 1 Failed 1 test script out of 1, 0.00% okay. Its a little messy, but it works. I'd welcome help making it look nicer. However t/test.pl (the low-fat Test::More substitute which almost everything in t/ uses) puts its diagnostics on STDOUT which gets sucked up by Test::Harness. That could be changed. As for providing further information at the end of a Perl core test run, that requires modifying t/TEST which has its own set of mental health problems. Finally, if you want to see real movement in improving the state of 'make test' output, help out finishing up Test::Harness 2.00 http://www.pobox.com/~schwern/src/Test-Harness-2.00_01.tar.gz and finishing the ExtUtils::* tests so we can work on that safely (the lives of MakeMaker and Test::Harness being intertwined). -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One An official "I want James Earl Jones' cock up my ass" t-shirt. http://www.goats/com/archive/010303.html
Re: Untested modules update: There's more than we thought
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. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Is there an airport nearby or is that just my tae-kwon-do taking off?
[ANNOUNCE] Test::Harness 2.00 release candiate 2
The second [1] Test::Harness 2.00 release candidate just went up to CPAN http://www.pobox.com/~schwern/src/Test-Harness-2.00_04.tar.gz As Test::Harness is a rather critical module, and this release is a fairly major reshaping of the internal code, I'm going to do a round of release candidates so people can shake out the bugs. The first one that lasts a week in the field wins. Simply install the module, let me know if it went ok and your perl -V and go about your normal business. If something goes wrong, if you suspect Test::Harness screwed up a 'make test', if you get a warning, etc... post the bug to me and/or [EMAIL PROTECTED] Users of non-Unix, or non-mainstream Unix, I'd particularly like to hear from. Now would be a good time to fire up the CPAN shell and install a bunch of modules you've been meaning to upgrade. CPAN module authors may want to check their modules against this new harness. Those interested in testing will want to look at the new Test::Harness::Straps programatic interface to the harness. Its not complete, but at least there is a way to tell if a test passed or failed without eyeballing the output. I've decided that if I wait until the Test::Harness::Straps interface is complete I'll never release the damned thing. So I'm planting my flag and starting the fight from here. [1] The first one lasted about 5 minutes thanks to Gil. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Our business in life is not to succeed but to continue to fail in high spirits. -- Robert Louis Stevenson
Re: Untested modules update: There's more than we thought
Thinks like use_ok, require_ok, isa_ok, can_ok, etc... are all functions that I threw into Test::More because I found myself needing them and suspected others did, too. If you prefer to use ok() instead of one of the above special purpose functions, I'm not going to jump up and down and fling poo at you (as enjoyable as that is). They're nice to have, which reflects the "More" nature of Test::More. If they didn't exist, I could see worrying about their utility weight against the effort involved in implementing them. But some crazy test monkey already implemented them, so there they are. Ooop ooop. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One my anus yearns now warm paste fills me happily saturday morning -- imploded
Test::Harness::Straps interface changes
Forgot to mention, there are a few user visable interface changes to Test::Harness::Straps in 2.00_03 (and thus _04) that have changed since 2.00_01. * 'summary' is now 'details'. It wasn't much of a summary. * Test #1 is now element 0 on the details array. It works out better that way I think. * analyze_file() is more portable, but no longer taint clean -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One I'm going to have to hurt you on principle.
'make test_harness' for more test info as it happens
Kurt mentioned he'd like more verbose information about how the tests are progressing as it happens, rather than having to wait until the end. In the perl core, the normal 'make test' doesn't give you much information at all because it has to use a neutered harness. I just remembered, you can run "make test_harness" instead of "make test" and it will run the core tests through Test::Harness. Unless you're expecting a truly catastrophic failure, this is safe and it provides more information both about the progress of the test and exactly which tests failed at the end. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One conway: unit of mind expansion. One Conway == ~20 lines of Perl code found in $CPAN/authors/id/D/DC/DCONWAY, which gives the sensation of your brain being wrapped around a brick, with kiwi juice squeezed on top. -- Ziggy
Re: Untested modules update: There's more than we thought
On Sun, Dec 16, 2001 at 04:20:33PM +, Nicholas Clark wrote: > Does that mean that it should have its own tests placed in t/lib, so that > they run before ext/ and lib/? Yes, it would be nice if they ran before the rest, but I really don't want to start shuffling tests around this close to 5.8. Anyhow, its usually Really Obvious when Test::More starts failing. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One This is my sig file. Is it not nify? Worship the sig file. http://www.sluggy.com
Re: Untested modules update: There's more than we thought
On Sun, Dec 16, 2001 at 11:09:29AM -0700, chromatic wrote: > + like( $$out, qr/could not locate your pod2man/, > + '... should warn if pod2man cannot be located' ); Gerrit, do you already have a perl installed in the spot you're about to put this new one? If so, it might be seeing that pod2man. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Pancakes is the better part of valor. http://www.goats.com/archive/971202.html
Re: Untested modules update: There's more than we thought
On Sun, Dec 16, 2001 at 02:41:31PM +, Piers Cawley wrote:
> Nothing wrong with an adaptor/factory returning something that isn't a
> Foo, so long as it has the same interface.
That's why its isa_ok() and not ref_ok().
On the off chance Foo->new is supposed to return something that bears
no relation to Foo at all, then just don't use isa_ok. Or, check that
its that other thing:
my $foo = Foo->new;
isa_ok( $foo, 'Bar' );
> > The equivalent code without isa_ok() would be:
> >
> > my $foo = Foo->new;
> > ok( $foo->isa('Foo') );
> >
> > except should $foo be unblessed or undef that will explode. You have
> > to start doing things like:
> >
> > my $foo = Foo->new;
> > ok( defined $foo && $foo->isa('Foo') );
> >
> > which rapidly gets tiresome. It also provides you little information
> > about what value $foo held that caused it to fail.
>
> What's wrong with
>
> ok ( eval { $foo->isa('Foo') } );
>
> or even:
>
> ok (eval { ref($foo) && $foo->isa('Foo') });
As Kurt already pointed out, you can do:
ok( UNIVERSAL::isa($foo, 'Foo') );
but if it fails you have no idea what $foo was.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
First day in Prison
Back behind the shower door
Adhesive applied
-- ignatz
Re: lib.t (was Re: Untested modules update: There's more than we thought)
On Sun, Dec 16, 2001 at 07:30:37PM +, Nicholas Clark wrote: > > I just thought of a better way. Since all we're testing is that > > lib.pm does the right things to @INC, we can presume that if one of > > require(), do() or use() works, the rest will work. > > Can't we just test what @INC now contains by directly reading it? > I'm assuming that it's safe for the test to assume that do/require/use > work with @INC correctly. Technically, yeah. But Brent's already gone that extra mile. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Any sufficiently encapsulated hack is no longer a hack.
Re: [ANNOUNCE] Test::Harness 2.00 release candiate 2
On Sun, Dec 16, 2001 at 12:07:36PM +0100, Abe Timmerman wrote: > Failed Test Stat Wstat Total Fail Failed List of Failed > --- > t\strap-analyze.t 18 460819 18 94.74% 2-19 > t\strap.t 12 3072 146 12 8.22% 51 57 63 75 80 87 98 100 105 > 111 116 123 > Failed 2/7 test scripts, 71.43% okay. 30/225 subtests failed, 86.67% okay. > > Sorry, I did look into the failed tests, but I don't understand the > Test::Harness::Straps::analyze_file() logic. MSWin32 doesn't support the open() > constructs with '-|' and '|-'. Those should be gone in 2.00_04. Are you sure you grabbed the right version? What $VERSION is Test::Harness::Straps? -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One gleam comes to my eyes as I combine pure water and triticale. -- mjd
Re: [ANNOUNCE] Test::Harness 2.00 release candiate 2
On Sun, Dec 16, 2001 at 10:53:14PM +0100, Abe Timmerman wrote: > Doh, my bad, I had 2.00_01 hanging around on my system. > > Works ok on both my regular ActivePerl 5.6.1 (build 628) and freshly compiled > bleadperl Yay! Thanks. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One First day in Prison Back behind the shower door Adhesive applied -- ignatz
Re: Untested modules update: There's more than we thought
On Sun, Dec 16, 2001 at 09:30:18PM -0500, Benjamin Goldberg wrote: > Suppose we have RandomThing->new which randomly returns an instance of > one of a few dozen different classes, which have no relation at all with > each other except a common interface. In such an odd case, don't use isa_ok(). Simp. > I think that if "all" we know about the returned type is that it is > supposed to provide some specific interface, it would be more robust to > test that the returned thing actually *does* provide the interface. As the ratio of constructors which return objects of random classes to those which produce something a bit more predictable is tiny, I'm not going to start assuming every constructor produces weird objects. Its more robust to do both. Check you got the right type and check the interface. On the off chance that the internals change to start producing randomly typed, yet interface conforming, objects, just change the tests. PS Do you know of anything that does return unpredictably typed objects? -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One 36 haikus would scare the shit out of me. Thank goodness for paste! -- Schwern
Re: v0.3 [Was: CPAN Upload: R/RB/RBS/Test-Differences-0.2.tar.gz]
On Sun, Dec 16, 2001 at 11:20:11PM -0700, chromatic wrote: > On Saturday 15 December 2001 11:44, Ilya Martynov wrote: > > > MGS> The two modules can already work together in the same script. So, if > > MGS> you have Test::Differences, which has superior complex data structure > > MGS> handling, why are you calling is_deeply() in the first place? > > > Still it is quite intersting idea to separate tests and results > > printing. Imaging that you can have pluggable output modules. So with > > one module you can have compact output with just ok/not ok, with > > another module you can build detailed report. > > Yeah, that's what I meant. The existing version works pretty well with > Test::Harness, but if someone (with GUI talent) wanted to write a nice Tk or > wx or GTK frontend, it'd be nice not to have to parse Test::Harness-style > results. > > That's really more of a Test::Builder style change, though. Worth > considering for the not-near future. Its more of a Test::Harness::Straps thing, which is available now in the Test::Harness 2.00 alpha. Add GUI talent to taste. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Lo, paste enema incarnation of the phrase anal retentive -- brevity
Re: v0.3 [Was: CPAN Upload: R/RB/RBS/Test-Differences-0.2.tar.gz]
On Mon, Dec 17, 2001 at 04:10:30PM +0900, Tatsuhiko Miyagawa wrote: > > I can understand that :) since CPAN is/seems a non-started for a > > significant number of folks (I have a Win32 system that it's > > nonfuncitonal on; haven't debugged it yet). > > I think Test::Differences is mainly for module developpers, not > for module users, thus the necessity for Test::Differences would > be better optional in distributing modules. There's always the "chuck it in t/lib" approach. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Ooops, fatal mutation in the test script.
Re: Untested modules update: There's more than we thought
On Mon, Dec 17, 2001 at 08:12:43AM +, Piers Cawley wrote:
> >> What's wrong with
> >>
> >> ok ( eval { $foo->isa('Foo') } );
> >>
> >> or even:
> >>
> >> ok (eval { ref($foo) && $foo->isa('Foo') });
> >
> > As Kurt already pointed out, you can do:
> >
> > ok( UNIVERSAL::isa($foo, 'Foo') );
> >
> > but if it fails you have no idea what $foo was.
>
> No you can't. Not if you've overridden isa anywhere. (Which is
> perfectly possible.)
Ooooh, hadn't thought about that. I've done it myself a few times (to
make a delegation look like inheritance). Now I have to go fix
Test::More to deal with it. Ya know, I was literally just about to
release 0.40 and I HAD to go read my email first.
Either way, your above ok() solutions still give you no failure
diagnostics, which is the whole point.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
pleasing symmetry
the paste goes in at one end
comes out the other.
-- mjd
Re: HELP: mod_perl and Apache::Cookie
On Sun, Dec 16, 2001 at 04:38:44PM -0500, Philip M. Gollucci wrote: > given the following setup: > Embedded Perl version v5.6.1 for Apache/1.3.22 (Unix) mod_python/2.7.6 > Python/2.1.1 PHP/4.0.6 mod_perl/1.26 process 8458, > > uname -a > FreeBSD xxx.com 4.4-RELEASE FreeBSD 4.4-RELEASE #1: Thu Dec > 13 08:25:04 EST 2001 > [EMAIL PROTECTED]:/usr/src/sys/compile/PHILIP i386 > > Someone Please Tell me what I am missing with Apache::Cookie > > because the folling script works fine if I: > replace Apache::Cookie->new($r, with &cookie() from CGI I think you may have strayed onto the wrong mailing list. This is the list for discussing Perl's QA infrastructure. Figuring out why mod_perl is spitting on you would better be done on one of the mod_perl mailing lists here: http://perl.apache.org/#maillists If anyone one on perl-qa wants to help out, just make sure you don't CC the list. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One There is nothing wrong. We have taken control of this sig file. We will return it to you as soon as you are groovy.
[ANNOUNCE] Test::Simple/More/Builder/Tutorial 0.40
Big release here, folks. Lots of new stuff, knocked off a good chunk
of the TODO list.
http://www.pobox.com/~schwern/src/Test-Simple-0.40.tar.gz
0.40 Fri Dec 14 15:41:39 EST 2001
* isa_ok() now accepts unblessed references gracefully
- Nick Clark found a bug with like() and a regex with % in it.
- exit.t was hanging on 5.005_03 VMS perl. Test now skipped.
- can_ok() would pass if no methods were given. Now fails.
- isnt() diagnostic output format changed
* Added some docs about embedding and extending Test::More
* Added Test::More->builder
* Added cmp_ok()
* Added todo_skip()
* Added unlike()
- Piers pointed out that sometimes people override isa().
isa_ok() now accounts for that.
Here's the juicy bits:
isa_ok()
Handles unblessed refs now -> isa_ok([], 'ARRAY');
Better diagnostics.
not ok 1 - The object isa Bar
# Failed test (-e at line 1)
# The object isn't a 'Bar' its a 'Foo'
cmp_ok()
The is_op() thing I was talking about. Nick, no more need to lie
awake at night worrying about testing numbers with is().
cmp_ok($some_horrendous_number, '==', $another_massive_number);
# Failed test (-e at line 1)
# got: 2420983.14598
# expected: 2420983.145981
In the == case the diagnostics force numeric context, so you can
safely do things like:
cmp_ok($!, '==', 5);
# Failed test (-e at line 1)
# got: 2
# expected: 5
cmp_ok($!, 'eq', "No such file or martian");
# Failed test (-e at line 1)
# got: 'No such file or directory'
# expected: 'No such file or martian'
but it means you also get:
cmp_ok("foo", '==', 5);
# Failed test (-e at line 1)
# got: 0
# expected: 5
which I think is the Right Thing. Thoughts?
I've gone through some pains to make the diagnostic output come
out just right, but I still think it looks a little ugly in the
non 'eq' and '==' cases.
cmp_ok(0, "&&", "foo")'
# Failed test (-e at line 1)
# '0'
# &&
# 'foo'
Let me know what you think.
Test::More->builder
Used to be to get access to the Test::Builder object underlying
Test::Builder you'd just call Test::Builder->new. In order to
cover my ass in case I discover that's a bad idea,
Test::More->builder is now the official way to get at the underlying
object. Though I just realized I left a bunch of Test::Builder->new
calls in the tests.
unlike()
Opposite of like()
todo_skip()
Combines a todo test with skip's ability to jump whole blocks.
Useful for when a todo test can't be run at all because it will
die or otherwise cause havoc. Doesn't come up all that often,
but I found myself needing it a few times in the core tests.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
GOD made us funky!
Re: [ANNOUNCE] Test::Simple/More/Builder/Tutorial 0.40
On Mon, Dec 17, 2001 at 11:48:34AM +0100, Tels wrote:
> What about the problem that can_ok() doesn't increase the testcount number
> by the number of methods, but only by one?
Like I said, I tried it that way, didn't like it and changed the
behavior. Found myself having trouble keeping track of the test count
as @methods changed size.
The docs are now explicit about can_ok counting as a single test.
They also offer an alternative if you want the multiple increment
behavior:
No matter how many @methods you check, a single can_ok() call counts
as one test. If you desire otherwise, use:
foreach my $meth (@methods) {
can_ok('Foo', $meth);
}
That'll fail even if @methods is empty, the test count will be wrong.
> Contradicts the doc (and the changelog seems to contradict v0.17, since in
> v.017 it did increase by 1, too), also makes it hard to see whether can_ok()
> really does some looping or simple prints "ok $test\n";
The bug with can_ok() succeeding with no @methods has been fixed.
Trust your test library. Or at least trust that things will be fixed
rapidly. :)
> Please make can_ok() increase the testcount by the number of methods.
Couldn't now even if I wanted to. Been around too long, would break
too many tests.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Stupid am I? Stupid like a fox!
[ANNOUNCE] Test 1.19 license change and mod_perl bug fixes
Stas Bekman found a problem with the globals in Test.pm when run under mod_perl (ie. persistently). Test::More probably has the same problem. Also, the license has been changed from Artistic-only to same as Perl. http://www.pobox.com/~schwern/src/Test-1.19.tar.gz 2001-12-17 Michael G Schwern <[EMAIL PROTECTED]> * Release 1.19 - Resetting globals for mod_perl testing (thanks to Stas Bekman) - License change to be same as perl's -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One I'm spanking my yacht.
[ANNOUNCE] Test::Harness 2.00_05 (RC 3)
http://www.pobox.com/~schwern/src/Test-Harness-2.00_05.tar.gz Things look nice. This release contains only minor fixes, except on VMS where _04 exploded nicely. Should be 100% now, let me know otherwise. I'm trying to get rid of that extra newline in the output. t/00compile ok Its now safe to put -T on your tests in VMS. 2.00_05 Mon Dec 17 22:08:02 EST 2001 * Wasn't filtering @INC properly when a test is run with -T, caused the command line to be too long on VMS. VMS should be 100% now. - Little bug in the skip 'various reasons' logic. - Minor POD nit in 5.004_04 - Little speling mistak -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Hold on while I slip into something a little more naked.
Re: emitting messages in Test::*
On Wed, Dec 19, 2001 at 07:52:03AM -0500, Barrie Slaymaker wrote: > I noticed that Test::Builder offers the ability to emit messages with > s/^/# /mg, which is very nice. Can/should this capability be exposed > via Test::Simple, Test::More, etc? Its been on the TODO list to toss a diag() into Test::More. ok( ... ) || diag(...); for some reason I keep putting it off. Test::Simple won't get one, it would double the size of the API! ;) -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One The eye opening delightful morning taste of expired cheese bits in sour milk!
Re: is() with arbitrary comparisions
On Tue, Dec 11, 2001 at 01:52:12PM -0500, Kirrily Robert wrote: Are we doing the time warp again, or are the Huskies just tired of pulling the packets across the border? > How about: > > compare($foo, "<=", $bar) cmp_ok(). Close. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One "Let's face it," said bearded Rusty Simmons, opening a can after the race. "This is a good excuse to drink some beer." At 10:30 in the morning? "Well, it's past noon in Dublin," said teammate Mike [Joseph] Schwern. "It's our duty." -- "Sure, and It's a Great Day for Irish Runners" Newsday, Sunday, March 20, 1988
Re: Test::Builder: Multiple test libraries in one test.
On Thu, Dec 13, 2001 at 02:07:56PM -0500, Kirrily Robert wrote:
> Actually, Test::Mail doesn't work like that. It's more or less a
> wrapper around Test::More that handles incoming email. Doesn't
> implement any of its own ok()-like routines at all, just makes it easy
> to use Test::More's routines on incoming email.
Ahh, in that case I might suggest instead of doing:
*Test::Simple::TESTOUT = \*LOG;
*Test::Simple::TESTERR = \*LOG;
*Test::More::TESTERR = \*LOG;
eval qq(
package $package;
use Test::More 'no_plan';
&${package}::$sub;
);
which I have a feeling isn't going to work anymore, those filehandles
are gone, you should do:
$t = Test::Builder->new;
$t->output(\*LOG);
$t->failure_output(\*LOG);
$t->todo_output(\*LOG);
eval qq(
package $package;
use Test::More 'no_plan';
\n#line 1 $msgid
&${package}::$sub;
);
The "#line 1 $msgid" bit is so the failure output doesn't all say
"Failed at /usr/local/share/perl/5.6.1/Test/Mail.pm line 58". But
instead maybe something a little more meaningful like "Failed at
[EMAIL PROTECTED] line 4" so you can at least track it back
to the email which caused the problem.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
you're a bleeding-heart
liberal. LET ME PLUG MY
ASS WITH PASTE RIGHT NOW!
-- japhy
Re: [PATCH] Re: emitting messages in Test::*
On Wed, Dec 19, 2001 at 12:20:35PM -0700, chromatic wrote: > Something like this? Something uncannily like this, only without the literal tabs. > diffing against a directory tree is odd... there must be a better > way. I usually just check each individual file into RCS (vc-register-buffer for the emacs heads) and then use rcsdiff -u on the files I've changed when I'm done (vc-diff). Thanks. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One and I pull out the Magnum from under the desk where I keep it in case someone laughs at a joke that's so dry it's got a built in water-fountain, and blow the lot of them away as a community Service. -- BOFH
Re: is() with arbitrary comparisions
Tels posted some of his Test::More experiences off-list. Some of them are rather good so I'll post my reply on-list. On Wed, Dec 19, 2001 at 10:42:55PM +0100, Tels wrote: > * Use Test::Simple/More for new testfiles. It can help you. If Test::More > scares you, use Test::Simple or only a subset of T::M. > * Don't convert old tests needless, better spent the time adding tests. > (But the conversation might take little time so try it if you have only a > small testsuite). If it makes you feel any better, I still have heaps of modules which I haven't bothered to convert over to Test::More. I do it when I find myself needing a Test::More feature and usually not before. > For the Test-developers: > > * Test::More is already quite confusing (Especially since ok() is no longer > what it used to be and you now must use is()!). Actually, Test::More's ok() is just like Test's ok(). And its not. Test.pm's ok() has at least three forms of operation. ok( $foo eq $bar ); # like Test::More::ok() ok( $foo, $bar ); # like Test::More::is() ok( $foo, qr/bar/ );# like Test::More::like() and then there's some of the more out there functionality: ok( $foo, $bar ); # like is( &$foo, $bar ); if $foo happens to # be a code ref. I never understood why this # magic was added. ok( $foo, $bar ); # if $bar looks like a regex (ie. "/wibble/") # it works as like(). Otherwise its is(). # Sucks if $bar == '/usr/local/' So I preserved the first of the five (which just happened to correspond to the way I wrote my custom ok() functions) because it is the most generic of them all. You can write any test with it. I also decided that Test::More users would have to learn five different functions rather than learning one function with five different modes of operation. > Insted of spending time to add even more confusing functions that > are used very little (if at all), shouldn't we do something more > usefull? > > For instance, I know of a lot of CPAN modules without tests at all, and I > talked to a few authors, and even if they decide to add tests (after my > 'convincing' emails), it takes time, or never gets done, or the tests are > to simple and too few. An even more confusing Test::More might scare them > off even more. Don't hand them Test::More, hand them Test::Simple. Or Test::Tutorial which eases the user into the Test::More interface. I *might* be convinced into adding is() to Test::Simple. I tend to use that nearly as much as ok(). Test::More's interface is nearly complete. After diag() I don't think I'm going to be adding any more functions. The rest will be either Test::Builder methods or left to a 3rd party Test::Builder based mix-in module (a la Test::Differences) to handle. Of course, with Test::Builder you can make your own test library in your own image and not have to listen to me anymore. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Some like elmers glue but it needs reapplying. I use super glue. -- tlk
Re: is() with arbitrary comparisions
On Wed, Dec 19, 2001 at 05:39:45PM -0500, Michael G Schwern wrote: > > For instance, I know of a lot of CPAN modules without tests at all, and I > > talked to a few authors, and even if they decide to add tests (after my > > 'convincing' emails), it takes time, or never gets done, or the tests are > > to simple and too few. An even more confusing Test::More might scare them > > off even more. Looking again at Test::More's rather lengthy SYNOPSIS, I'll take kindly to doc reorganizations. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One sun readdened wheat stalks bowing down in autumn sun my mind wanders far -- stimps
[ANNOUNCE] Test::Simple/More/Builder/Tutorial 0.41
Small update. diag() has finally been added to Test::More, thanks to chromatic. Also, I noticed that internal eval()s were interfering with the outside's $@ and $!, so I protected against that. Why eval() is fiddling with $! I don't know. 0.41 Mon Dec 17 22:45:20 EST 2001 * chromatic added diag() - Internal eval()'s sometimes interfering with $@ and $!. Fixed. 0.40 Fri Dec 14 15:41:39 EST 2001 * isa_ok() now accepts unblessed references gracefully - Nick Clark found a bug with like() and a regex with % in it. - exit.t was hanging on 5.005_03 VMS perl. Test now skipped. - can_ok() would pass if no methods were given. Now fails. - isnt() diagnostic output format changed * Added some docs about embedding and extending Test::More * Added Test::More->builder * Added cmp_ok() * Added todo_skip() * Added unlike() - Piers pointed out that sometimes people override isa(). isa_ok() now accounts for that. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One i need another hit just gimme some fucking paste please, it hurts so bad -- Fmh
Untested modules update: The Magic Number is 27
The good news is lib.t and MM_Unix just went into the core. The even better news is Wolfgang Laun came riding in out of the East and has begun fixing perlcc! He's repairing B::Assembler and B::Disassembler and has written assembler.t And not to break the trend, the Net::Ping CPAN distribution already has a battery of tests which are ready-made for the core. Jarkko's looking to see if there's some reason we're not using them already. The bad news is the remaining Pod::* modules need a champion. And does anyone have a Netware machine so we can try out ExtUtils::MM_NW5? The magic number is 27 (26 if Net::Ping goes in). #B::Bytecode[module broken, can't test] #B::C [ditto] #B::CC [ditto ditto] #B::Concise [[EMAIL PROTECTED]] #B::Disassembler[Wolfgang Laun] #B::Lint[[EMAIL PROTECTED]] #B::Stackobj[[EMAIL PROTECTED]] #B::Xref[[EMAIL PROTECTED]] Byteloader CPAN # CPAN::FirstTime [[EMAIL PROTECTED]] in progress Dynaloader ExtUtils::MM_NW5 # ExtUtils::MM_OS2 [[EMAIL PROTECTED]] ExtUtils::MM_VMS [exists, but needs some lovin'] # ExtUtils::MM_Win32 [[EMAIL PROTECTED]] ExtUtils::Install ExtUtils::Liblist ExtUtils::Mksymlists # Net::Cmd [[EMAIL PROTECTED]] Net::Domain # Net::Ping [[EMAIL PROTECTED] (could be taken from the CPAN dist)] Net::POP3 # O [[EMAIL PROTECTED]] in progress Pod::Functions (no docs!) Pod::Html Pod::InputObjects Pod::Select Pod::Usage # re [[EMAIL PROTECTED]] proposed patch on p5p -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One I'm exploring my nipples.
Re: [ANNOUNCE] Test::Simple/More/Builder/Tutorial 0.40
On Fri, Dec 21, 2001 at 04:00:34PM +0100, Philip Newton wrote: > On Mon, 17 Dec 2001 04:52:13 -0500, [EMAIL PROTECTED] (Michael G > Schwern) wrote: > > > isa_ok() > > Handles unblessed refs now -> isa_ok([], 'ARRAY'); > > > > Better diagnostics. > > not ok 1 - The object isa Bar > > # Failed test (-e at line 1) > > # The object isn't a 'Bar' its a 'Foo' > > Is that real copy-n-paste from some sample output? > > If so, please replace q(its) with q(it's) in the code. (And I'd also add > a comma or a semicolon after the 'Bar': "The objects isn't a 'Bar'; it's > a 'Foo'" or the like.) I can never keep it straight when to put an apostrophe on /it'?s/, so as a long-time user of English (almost 24 years now) I've decided to alter my implementation of the language and drop the apostrophe entirely. 'its' is now polymorphic as far as I'm concerned. The Apostrophilic Jihad could submit a patch after meditating on this: http://www.angryflower.com/bobsqu.gif -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Let me check my notes. http://www.sluggy.com
Re: [ANNOUNCE] Test::Simple/More/Builder/Tutorial 0.40
On Sat, Dec 22, 2001 at 03:13:12PM -0500, Aaron J Mackey wrote: > > On Fri, 21 Dec 2001, Michael G Schwern wrote: > > > I can never keep it straight when to put an apostrophe on /it'?s/ > > It's very simple. If you can replace the "its" with "it is", then there's > an apostrophe to denote the contraction. > > If you need another simple rule, think about this: "hers, his, its", not > "her's, hi's, it's". Thank you. I'll file that away in my brane along with such other important information like the number of times President Ford tripped in public and the words to the Oscar Meyer Bologna song. :P -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One It wasn't false, just differently truthful. -- Abhijit Menon-Sen in <[EMAIL PROTECTED]>
Re: [ANNOUNCE] Test::Simple/More/Builder/Tutorial 0.40
On Sat, Dec 22, 2001 at 09:48:22AM +0100, Philip Newton wrote: > > after meditating on this: http://www.angryflower.com/bobsqu.gif > > That oversimplifies things a bit; the rule "possessive things take > apostrophe-s" doesn't apply to pronouns. Fascinating. Thanks for the patch. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One make a channel called #Perl, and infest it with joking and fun it doesnt make alot of sense.
[ANNOUNCE] Test::Harness 2.00
The official Test::Harness 2.00 release just went out to CPAN. If all goes according to plan, most people shouldn't even notice a difference. Please report any bugs or odd output. http://www.pobox.com/~schwern/src/Test-Harness-2.00.tar.gz Revision history for Perl extension Test::Harness 2.00 Sun Dec 23 19:13:57 EST 2001 - Fixed a warning on VMS. - Removed a little unnecessary code from analyze_file() - Made sure filehandles are getting closed - analyze() now considers "not \nok" to be a failure (VMSism) but Test::Harness still doesn't. 2.00_05 Mon Dec 17 22:08:02 EST 2001 * Wasn't filtering @INC properly when a test is run with -T, caused the command line to be too long on VMS. VMS should be 100% now. - Little bug in the skip 'various reasons' logic. - Minor POD nit in 5.004_04 - Little speling mistak -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One MERV GRIFFIN!
Re: Untested modules update: The Magic Number is 27
On Thu, Dec 27, 2001 at 09:11:26AM -0800, Benjamin Stuhl wrote: > --- Michael G Schwern <[EMAIL PROTECTED]> wrote: > [... and the shears went snip, snip, ker-snip ...] > > #B::Bytecode[module broken, can't test] > > #B::C [ditto] > > #B::CC [ditto ditto] > > #B::Concise [[EMAIL PROTECTED]] > > #B::Disassembler[Wolfgang Laun] > > #B::Lint[[EMAIL PROTECTED]] > > #B::Stackobj[[EMAIL PROTECTED]] > > #B::Xref[[EMAIL PROTECTED]] > > Byteloader > > Byteloader is untestable without a working B::Bytecode (we > have no way of generating input files for it. I'm holding out for Wolfgang, he may yet be able to fix them. > Anyway, Byteloader/B::Bytecode are actually speed _losses_, so IMHO > they should probably simply be killed - they're just wasted > space in the distribution. (IIRC, I was the last person to > seriously hack on them.) And if they get removed from the > core, they obviously don't need tests ;-). You are wise. :) > > CPAN > > # CPAN::FirstTime [[EMAIL PROTECTED]] in progress > > Dynaloader > > What sort of test does Dynaloader need? If dynaloading > doesn't work, no dynamic extensions (Socket, Fcntl, IO, > POSIX, ...) will work, and the errors they'll spew are > pretty obviously loading problems. Dynaloader has a good sized documented interface which isn't necessarily exercised by the core modules. Test that. Its also nice to know something a little more organized than "something exploded when I tried to build Perl". And when hacking on DynaLoader, its easier to run a fast test suite than to rebuild Perl every time you want to check if you broke something leaving the ultimate rebuild check to the end. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Schwern Unit: a positive but insignificant quantity
Re: Testing Tests
On Wed, Jan 02, 2002 at 05:10:14PM +, Mark Fowler wrote:
> Is there any commonly accepted knowledge about how one should write tests
> for "Test" modules that one might construct using Test::Builder? In
> particular, how does one test that one of your new test fails when it
> should?
>
> I did have an idea about how nice it would be if you could call a method
> in Test::Builder that would cause the next call to ok() to fail if it
> should pass and vice versa (and return true where it would have returned
> true and false when it would have returned true.)
Since everything winds up using ok() (though that's not officially
documented, I'll do that) you can simply override Test::Builder::ok().
sub My::Builder::ok {
my($self, $test, $name) = @_;
$self->SUPER::ok(!$test, $name);
}
but that only checks that the basic test logic is ok. None
of your diagnostic output is checked.
In order to check diagnostic output...
Redirect the error output to a simple tied filehandle (PRINT is
about all you need) using Test::Builder->failure_output and
todo_output.
Examine the output stored in the tied filehandle to see if its
what you expected.
Test::Simple/More/Builder's t/fail*.t tests do this in varying levels
of contortions. They're a bit brutish since they largely predate
Test::Builder and can't trust it anyway, having to do odd things like
writing its own ok() function.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Do you actually think about what you are saying or is it an improvisational
game of Mad Libs that you play in your head?
Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C )
On Wed, Jan 02, 2002 at 05:37:28PM +0100, Mattia Barbon wrote: > I don't care for the variable name, but I'd really like > to have this feature. Would it work ok as a Test::Builder accessor method rather than an environment variable? -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Nature is pissed. http://www.unamerican.com/
Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C )
On Sat, Jan 05, 2002 at 10:17:34PM +0100, Mattia Barbon wrote: > > On Wed, Jan 02, 2002 at 05:37:28PM +0100, Mattia Barbon wrote: > > > I don't care for the variable name, but I'd really like > > > to have this feature. > > > > Would it work ok as a Test::Builder accessor method rather than an > > environment variable? > No, unfortunately, because the call order is like this: > * init code in the backend > * BEGIN blocks of the program ( including use Foo; ) > * B::Backend::compile > * the coderef returned by B::Backend::compile > > So I can't call the method from the init code in the backend, > because Test::Builder hasn't been loaded yet, and calling it from > the ::compile is too late ( output is already lost ); the > alternative I see is to use a package variable; so I can set > $Test::Builder::i_want_the_output_even_if_dollar_caret_C_is_1 = 1; > in initialization code. You could do this: require Test::Builder; my $tb = Test::Builder->new; $tb->output_even_if_compiling(1); in the init code. Since Test::Builder is a singleton your settings should stick. Here's an interesting alternative. Do C just before running the tests, though that's pretty ugly. > But I rwally like the environment variable better, because with the > package variable solution I need to set it unconditionally ( because > for it to have effect it must be set in the init code, and in the > init code I can't look at parameters, because parameters are passed > in the call to compile, so I can't set it using a parameter ), and > because I was hoping to keep B::C clear from > hacks-to-make-the-testsuite-happy. >From my PoV, I'm hoping to keep Test::Builder clear from hacks-to-make-perlcc-happy. :) The $^C thing is already a hack for B::Deparse. Could you explain again why you need test output while compiling, I'm not quite following. Assume you had the I_WANT_OUTPUT_DURING_COMPILE environment variable could you show how you'd be using it? -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One I've heard that semen tastes different depending on diet. Is that true? Hello? Skrewtape: Hang on, I'm conducting research.
Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C )
On Sun, Jan 06, 2002 at 03:56:24PM +0100, Mattia Barbon wrote:
> > Could you explain again why you need test output while compiling, I'm
> > not quite following. Assume you had the I_WANT_OUTPUT_DURING_COMPILE
> > environment variable could you show how you'd be using it?
>
> Let's say I have this lib/Bar/t/bar.t ( not usint Test::* )
>
> #!perl
>
> BEGIN { print "1..2\n" };
> BEGIN { print "ok 1" };
>
> print "ok 2\n";
>
> This prints "1..2\nok 1\n" at compile time, and "ok 2\n"; at run
> time. When compiled with "perlcc --testsuite bar.t", perlcc saves
> the compile-time output, and passes to B::C the
> -e"print qq{1..2\nok 1\n}" option ( -efoo means "eval foo just before
> you run the program" ); so the compiled program prints
> 1..2
> ok 1
> ok 2
> and t/TEST is happy
>
> However lib/Foo/t/foo.t uses Test::Simple
>
> #!perl
>
> use Test::Simple tests => 2;
>
> BEGIN { use_ok('Foo') }
>
> ok( foo(1), "foo(1) is true" );
>
> So when compiled with B::C, $^C is set, and it does
> not print the "1..2\nok 1\n" at all, so perlcc does not see it,
> does not pass anything to B::C, so the compiled
> program prints just "ok 2" and t/TEST is very unhappy.
> The I_WANT_BEGIN_OUT ( or whatever ) works around that.
> Hope it is clearer now.
I think I know what's going on. Follow me here...
You're compiling the test with B::C.
You're running the compiled program.
Code inside the BEGIN blocks has $^C set?? Or are they just not being
run at all? Either of those are bugs. But there's a third
possibility which I think is what's going on...
If you were to take:
BEGIN { print "foo" }
compile it and run it, would you expect the output to be 'foo'? Or is
the problem that you're getting 'foo' both during the compilation
*and* when its run? As with this:
$ ./perl -Ilib -MO=Deparse -e 'BEGIN { print "foo\n" }'
foo
sub BEGIN {
print "foo\n";
}
;
-e syntax OK
if its that, you can do this:
$ ./perl -Ilib -MO=-qq,Deparse -e 'BEGIN { print "foo\n" }'
sub BEGIN {
print "foo\n";
}
;
pass the -qq option to O.pm to make it both supress STDOUT and the -e
syntax OK. Then it'll work as expected even with the $^C hack.
$ ./perl -Ilib -MO=-qq,Deparse -e 'BEGIN { print "ok 1\n" } print "ok 2\n"' | ./perl
ok 1
ok 2
$ ./perl -Ilib -MO=-qq,Deparse -e 'BEGIN { print "ok 1\n" unless $^C } print "ok
2\n"' | ./perl
ok 1
ok 2
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Follow me to certain death!
http://www.unamerican.com/
Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C )
On Sun, Jan 06, 2002 at 09:46:13PM +0100, Rafael Garcia-Suarez wrote: > Instead of using an environment variable, you can use a global variable > in the O namespace. Let's say $O::No_Test_Output defaults to 1 (set by > O.pm). > > In Test::Builder (line #571) you would have > return if $O::No_Test_Output; # Don't print headers under compiler backends > instead of > return if $^C; > and B::C (and other backends that want to behave this way) > could override this setting by doing $O::No_Test_Output = 0. That's just as yicky as an environment variable. Both involve incestuous coupling. Hopefully it turns out that -qq will fix this. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One I will personally promise to glare sternly at such people. -- Jarkko Hietaniemi in <[EMAIL PROTECTED]>
[ANNOUNCE] Test::Harness 2.01 now with Test::Harness::Straps example
http://www.pobox.com/~schwern/src/Test-Harness-2.01.tar.gz Test::Harness 2.00 didn't cause any disasters (people are actually using it, right?) so here's 2.01. 2.01 Thu Dec 27 18:54:36 EST 2001 * Added 'passing' to the results to tell you if the test passed * Added Test::Harness::Straps example (examples/mini_harness.plx) * Header-at-end tests were being interpreted as failing sometimes - The 'skip_all' results from analyze* was not being set - analyze_fh() and analyze_file() now work more efficiently, reading line-by-line instead of slurping as before. I'll discuss the Straps example in a seperate post. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Hey, Schwern! THERE IS A HUGE GAZORGANSPLATTEDFARTMONGERING- LIGHTENINGBEASTASAURSOPOD BEHIND YOU! RUN, BEFORE IT GAFLUMMOXES YOUR INNARDLYBITS!
Test::Harness::Straps example.
I want to finish the Test::Harness::Straps interface so its usable. But I can't finish it until people play with it some and I get some feedback. But people won't use it until its usable. Wash, rinse, repeat. To break the loop I've added some new experimental, undocumented features to Test::Harness::Straps so you can emulate the bulk of Test::Harness's behavior. 2.01 has an example in examples/mini_harness.plx. This is small reproduction of Test::Harness. You feed it some test files, it runs them and prints ok/not ok for each. The experimntal bit is the callback interface. For each line of the test read in the callback is run giving the line read, the type (test, bailout, other) and the current running totals. This is so you can report on the test as it is run, like Test::Harness does. It all works, I just don't think the interface is very pleasant. So I'd like people to play around with it and tell me what you think. Many people have suggested new features for Test::Harness over the years, now you can do whatever you like. Here's a grab bag to try: - Alter it so the tests are run in random order - Or each is run multiple times (in case of intermittent failure) - Or each test is run several times in parallel (to check for weird interactions) - Alter the output format so it prints out XML, HTML, YAML, etc... - Make it send email on success/failure -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One I know you get this a lot, but you're breathtaking, like a vision of simplicity
[PATCH t/run/kill_perl.t t/test.pl] Seperating kill_perl()
As long ago promised, here's a patch to pull the logic out of
t/run/kill_perl.t and make it into a t/test.pl function.
This means its no longer necessary to pile segfault checks into
t/run/kill_perl.t. They can be placed in the appropriate test file
like so:
kill_perl(<{progfile} = $tmpfile;
+$runperl_args->{stderr} = 1;
+
+open TEST, ">$tmpfile" or die "Cannot open $tmpfile: $!";
+
+# VMS adjustments
+if( $^O eq 'VMS' ) {
+$prog =~ s#/dev/null#NL:#;
+
+# VMS file locking
+$prog =~ s{if \(-e _ and -f _ and -r _\)}
+ {if (-e _ and -f _)}
+}
+
+print TEST $prog, "\n";
+close TEST or die "Cannot close $tmpfile: $!";
+
+my $results = runperl(%$runperl_args);
+my $status = $?;
+
+# Clean up the results into something a bit more predictable.
+$results =~ s/\n+$//;
+$results =~ s/at\s+misctmp\d+\s+line/at - line/g;
+$results =~ s/of\s+misctmp\d+\s+aborted/of - aborted/g;
+
+# bison says 'parse error' instead of 'syntax error',
+# various yaccs may or may not capitalize 'syntax'.
+$results =~ s/^(syntax|parse) error/syntax error/mig;
+
+if ($^O eq 'VMS') {
+# some tests will trigger VMS messages that won't be expected
+$results =~ s/\n?%[A-Z]+-[SIWEF]-[A-Z]+,.*//;
+
+# pipes double these sometimes
+$results =~ s/\n\n/\n/g;
+}
+
+$expected =~ s/\n+$//;
+
+my $pass = $results eq $expected;
+unless ($pass) {
+print STDERR "# PROG: $switch\n$prog\n";
+print STDERR "# EXPECTED:\n$expected\n";
+print STDERR "# GOT:\n$results\n";
+print STDERR "# STATUS: $status\n";
+}
+
+($name) = $prog =~ /^(.{1,35})/ unless $name;
+
+_ok($pass, _where(), "kill_perl - $name");
+}
+
1;
--- t/run/kill_perl.t 2002/01/11 08:42:45 1.1
+++ t/run/kill_perl.t 2002/01/11 09:24:36
@@ -1,5 +1,9 @@
#!./perl
+# ** DO NOT ADD ANY MORE TESTS HERE **
+# Instead, put the test in the appropriate test file and use the
+# kill_perl() function in t/test.pl.
+
# This is for tests that will normally cause segfaults, and other nasty
# errors that might kill the interpreter and for some reason you can't
# use an eval().
@@ -14,10 +18,6 @@
# to test that the code "($a, b) = (1,2)" causes the appropriate syntax
# error, rather than just segfaulting as reported in perlbug ID
# 20020831.001
-#
-#
-# NOTE: Please don't add tests to this file unless they *need* to be
-# run in separate executable and can't simply use eval.
BEGIN {
chdir 't' if -d 't';
@@ -40,13 +40,8 @@
$prgs[-1][0] .= $_;
}
}
-print "1..", scalar @prgs, "\n";
-
-my $tmpfile = "misctmp000";
-1 while -f ++$tmpfile;
-END { while($tmpfile && unlink $tmpfile){} }
+plan tests => scalar @prgs;
-my $test = 1;
foreach my $prog (@prgs) {
my($raw_prog, $name) = @$prog;
@@ -57,57 +52,7 @@
my($prog,$expected) = split(/\nEXPECT\n/, $raw_prog);
-open TEST, ">$tmpfile" or die "Cannot open $tmpfile: $!";
-
-# VMS adjustments
-if( $^O eq 'VMS' ) {
-$prog =~ s#/dev/null#NL:#;
-
-# VMS file locking
-$prog =~ s{if \(-e _ and -f _ and -r _\)}
- {if (-e _ and -f _)}
-}
-
-print TEST $prog, "\n";
-close TEST or die "Cannot close $tmpfile: $!";
-
-my $results;
-if ($^O eq 'MacOS') {
-$results = `$Perl -I::lib -MMac::err=unix $switch $tmpfile`;
-}
-else {
-$results = `$Perl "-I../lib" $switch $tmpfile 2>&1`;
-}
-my $status = $?;
-
-# Clean up the results into something a bit more predictable.
-$results =~ s/\n+$//;
-$results =~ s/at\s+misctmp\d+\s+line/at - line/g;
-$results =~ s/of\s+misctmp\d+\s+aborted/of - aborted/g;
-
-# bison says 'parse error' instead of 'syntax error',
-# various yaccs may or may not capitalize 'syntax'.
-$results =~ s/^(syntax|parse) error/syntax error/mig;
-
-if ($^O eq 'VMS') {
-# some tests will trigger VMS messages that won't be expected
-$results =~ s/\n?%[A-Z]+-[SIWEF]-[A-Z]+,.*//;
-
-# pipes double these sometimes
-$results =~ s/\n\n/\n/g;
-}
-
-$expected =~ s/\n+$//;
-my $ok = $results eq $expected;
-
-unless( $ok ) {
- print STDERR "# PROG: $switch\n$prog\n";
-print STDERR "# EXPECTED:\n$expected\n";
-print STDERR "# GOT:\n$results\n";
-}
-printf "%sok %d%s\n", ($ok ? '' : "not "), $test,
- length $name ? " - $name" : $name;
-$test++;
+kill_perl($prog, $expected, { switches => $switch }, $name);
}
__END__
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
It should indeed be said that notwithstanding the fact that I make
ambulatory progress through the umbragious inter-hill mortality slot,
terror sensations will no be initiated in me, due to para-etical phenomena.
Re: [PATCH t/run/kill_perl.t t/test.pl] Seperating kill_perl()
On Fri, Jan 11, 2002 at 05:35:04PM +0200, Jarkko Hietaniemi wrote:
> On Fri, Jan 11, 2002 at 05:31:49PM +0200, Jarkko Hietaniemi wrote:
> > On Fri, Jan 11, 2002 at 05:18:10PM +0200, Jarkko Hietaniemi wrote:
> > > > PS There was also a bug in runperl(). All switches were being lost.
> > >
> > > Well, this change made several tests (like run/switches) to barf.
> > > So I backed out that hunk.
> >
> > Urk, so now three of kill_perl tests tests are failing...
> > this is like quicksand.
>
> Okay, this seems to keep all happy:
>
> - _quote_args(\$runperl, $args{switches});
> + _quote_args(\$runperl,
> + ref $args{switches} ? $args{switches} : [$args{switches}]);
This is all my mistake. I misinterpreted the runperl() docs.
# Arguments :
# switches => [ command-line switches ]
switches takes an array ref. It was fine the way it was, t/run/kill_perl.t
was calling runperl() wrong. Patch below.
> A propos, something is quoting octothorpes quite eagerly:
>
> ok 76 - kill_perl - \# Bug 20010515.004
Yes, that's inside _ok() in t/test.pl. It has to do that else the
test name might interfere with "# todo" and "# skip". Actually, I
don't think t/TEST honors escaped # so its sort of moot in t/test.pl.
--- t/run/kill_perl.t 2002/01/11 21:39:17 1.1
+++ t/run/kill_perl.t 2002/01/11 21:39:21
@@ -52,7 +52,7 @@
my($prog,$expected) = split(/\nEXPECT\n/, $raw_prog);
-kill_perl($prog, $expected, { switches => $switch }, $name);
+kill_perl($prog, $expected, { switches => [$switch] }, $name);
}
__END__
--- t/test.pl 2002/01/11 21:38:32 1.1
+++ t/test.pl 2002/01/11 21:38:55
@@ -280,8 +280,7 @@
my %args = @_;
my $runperl = $^X;
if ($args{switches}) {
- _quote_args(\$runperl,
- ref $args{switches} ? $args{switches} : [$args{switches}]);
+ _quote_args(\$runperl, $args{switches});
}
unless ($args{nolib}) {
if ($is_macos) {
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
slick and shiny crust
over my hairy anus
constipation sucks
-- Ken Flagg
Re: [PATCH t/run/kill_perl.t t/test.pl] Seperating kill_perl()
On Fri, Jan 11, 2002 at 05:03:46PM +0200, Jarkko Hietaniemi wrote: > > The name of the function and order of arguments are all up for > > discussion. > > Thanks, applied. > > About the name: I think it's an awful name... doesn't tell me at least > at all what it's for (except maybe for doubling as CORE::dump()...). > fresh_perl()? kamikaze_perl()? At 5am the imagination is the first to go. I guess the idea is to run a program in a seperate process and compare the output. A cross between runperl() and is(). is_runperl() doesn't seem like a good idea. cmp_runperl? cmp_prog? -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One I have this god-awful need to aquire useless crap!!!
Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C )
On Tue, Jan 08, 2002 at 11:02:27PM +0100, Mattia Barbon wrote:
> > Code inside the BEGIN blocks has $^C set?? Or are they just not being
> > run at all? Either of those are bugs. But there's a third
>
> The code inside the begin blocks has $^C set ( as it should ), and they
> are being run
> ( as they should )
The code inside the BEGIN blocks has $^C set *only when compiling with
perlcc* right? If you run the bytecompiled code the BEGIN blocks
should not have $^C set.
Lemme recompile things and try this out.
> > If you were to take:
> >
> > BEGIN { print "foo" }
> >
> > compile it and run it, would you expect the output to be 'foo'? Or is
> > the problem that you're getting 'foo' both during the compilation
> > *and* when its run? As with this:
>
> I'd expect the output of the compiled program to be nothing _normally_
> ( perlcc foo.pl ),
> and "foo" _if I used the --testsuite switch when calling perlcc_
> ( perlcc --testsuite foo.pl ).
>
> And in order to not have to introduce hacks in t/TEST, I'd like
> that the compiled program resulting from
>
> use Test::Simple tests => 12;
>
> would print nothing normally, and 1..2 _if I passed the --testsuite
> switch to perlcc_ .
Now wait a second. Why would the compiled program print nothing
normally? $^C should not be set.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Instant Cross-Platform CGI Programming in Visual Perl 5 with Object Oriented
Design in 7 Days Unleashed for Dummies Special Edition with Exclusive Java
Chapters for Developers. Year 2000 compliant, Enterprise edition and ISO9000-
certified. A Nutshell Handbook Designed For Windows 95/98/NT with a forward by
Larry "Bud" Melman. Interactive Multimedia CDROM included. 3rd revised editon,
covers Perl5.6.
Of course, it will be refered to by its simple acronym:
ICPCGIPiVP5wOODi7DU4DSEwEJC4DY2KCEedISO9000-cNHD4W9598NTLBMIMCDROM3edP5.6
Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C )
perlcc seems to be dropping BEGIN blocks entirely, that's the problem.
# foo.plx
BEGIN {
print "foo\n";
}
print "bar\n";
$ bleadperl foo.plx
foo
bar
$ perlcc foo.plx
$ ./a.out
bar
The result from the compiled program should be the same as the
original. For some reason the BEGIN block is getting dropped when the
program is compiled. That's a bug.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
my anus yearns now
warm paste fills me happily
saturday morning
-- imploded
Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C )
On Sun, Jan 13, 2002 at 07:39:52PM +0100, Mattia Barbon wrote:
> > perlcc seems to be dropping BEGIN blocks entirely, that's the problem.
>
> No, that's correct. Explanation: if I have a module Foo
>
> package Foo;
>
> $x = 1;
> print "AAA";
>
> sub a { $x }
>
> 1;
>
> and a main program foo.pl
>
> BEGIN { # think use Foo;, expanded for clarity
> require Foo;
> }
>
> print Foo::a();
>
> perl -MO=C foo.pl
> calls B::C::compile _after_ it ran the BEGIN blocks; this means that the
> optree in Foo that initializes $x, and does "print AAA" has already been
> freed. So, even if B::C could save BEGIN blocks, this is not a good
> idea, for quite a lot of reasons.
$ bleadperl -MO=-qq,Deparse foo.plx
sub BEGIN {
print "foo\n";
}
print "bar\n";
If B::Deparse can save BEGIN blocks, B::C can.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
I have this god-awful need to aquire useless crap!!!
Compiled programs to keep BEGIN blocks? (was Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C ))
On Sun, Jan 13, 2002 at 10:04:58PM +0100, Mattia Barbon wrote:
> > $ bleadperl -MO=-qq,Deparse foo.plx
> > sub BEGIN {
> > print "foo\n";
> > }
> > print "bar\n";
> >
> > If B::Deparse can save BEGIN blocks, B::C can.
>
> I didn't mean that I can't write code to make B::C save BEGIN blocks
> ( it'd require <10 lines, probably ), I did mean that doing so would
> not be a god idea: _I am
> saving the state of the program after those blocks were ran_ and
> they will be run _another time_ at runtime, and this is not correct:
> ( for example use lib 'a'; would put 'a' into @INC twice, once
> ( correctly ) at compile time, and another time ( incorrectly ) at
> runtime ). In this
> case this is not harmful, but you get the idea.
I don't understand. The compiled program should do exactly what the
original program did. Anything else, as difficult as it may be, is a
bug. Lots of programs and modules do important load-time checks and
logic inside BEGIN blocks.
Why would this:
BEGIN {
push @INC, 'foo';
}
put 'foo' into @INC twice if it were compiled? The compiled program
should not be storing the post-BEGIN value of @INC, it should store
the original value at startup.
--
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: Compiled programs to keep BEGIN blocks?
On Mon, Jan 14, 2002 at 11:13:27AM +0100, Rafael Garcia-Suarez wrote:
> On 2002.01.13 22:25 Michael G Schwern wrote:
> > Why would this:
> >
> > BEGIN {
> > push @INC, 'foo';
> > }
> >
> > put 'foo' into @INC twice if it were compiled? The compiled program
> > should not be storing the post-BEGIN value of @INC, it should store
> > the original value at startup.
>
> The compilation occurs at CHECK-time, that is, after 'foo' has been pushed
> into @INC.
I don't know if this is true, but it isn't relevent. Remember, BEGIN,
INIT, CHECK, etc... time is only relevent to the current module being
loaded/run. As this example shows, Bar.pm's code is run before even
Foo.pm's BEGIN block. Replace -MBar with -MO=C and you get the idea.
# ~/tmp/Foo.pm
package Foo;
BEGIN {
push @INC, 'foo';
}
print "\@INC as Foo has modified it\n";
print join "\n", @INC;
# ~/tmp/Bar.pm
package Bar;
print "\@INC as Bar sees it\n";
print join "\n", @INC;
$ bleadperl -I/home/schwern/tmp -MBar -wle 'use Foo'
@INC as Bar sees it
/home/schwern/tmp
/usr/local/bleadperl/lib/5.7.2/ppc-linux-64int
/usr/local/bleadperl/lib/5.7.2
/usr/local/bleadperl/lib/site_perl/5.7.2/ppc-linux-64int
/usr/local/bleadperl/lib/site_perl/5.7.2
/usr/local/bleadperl/lib/site_perl
..
@INC as Foo has modified it
/home/schwern/tmp
/usr/local/bleadperl/lib/5.7.2/ppc-linux-64int
/usr/local/bleadperl/lib/5.7.2
/usr/local/bleadperl/lib/site_perl/5.7.2/ppc-linux-64int
/usr/local/bleadperl/lib/site_perl/5.7.2
/usr/local/bleadperl/lib/site_perl
..
foo
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
We're talkin' to you, weaselnuts.
http://www.goats.com/archive/000831.html
Re: Compiled programs to keep BEGIN blocks? (was Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C ))
On Mon, Jan 14, 2002 at 04:16:49PM +, Piers Cawley wrote:
> > Like I said, if B::Deparse can do it, B::C can.
>
> But it shouldn't. How do you distinguish between:
>
>use Foo;
>
> (needs to use 'Foo' before generating the compiled script, otherwise
> what's the bloody point?)
>
> and
>
>BEGIN { ... }
Using Deep Magic as demonstrated inside B::Deparse by begin_is_use().
Module::Info uses a rather simplified version for it's
modules_used() method.
Not easy, but definately a (mostly) solved problem.
> Also, as the docs for B::Deparse points out:
>
> we can't guarantee to produce BEGIN blocks or "use" declarations
> in exactly the right place.
>
> Which can become a big problem when you find that your compiled script
> doesn't work and there's no easy way of debugging the program that it
> thinks it's evaluating.
So is the answer to just exclude them entirely? That's the wrong way
out.
B::Deparse has slowly gotten very good at figuring out BEGIN blocks
from 'use' statements and putting them in the right places. Hard
fought knowledge. Steal from it.
I don't expect perlcc to magically become perfect overnight. What I
do expect is that the 'compiled programs won't run code in BEGIN
blocks' be treated as a bug and not a feature and to look around at
other bits of B which are taking a stab at solving these problems.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Well, my work here is done. If you need me again, just admit that you're
screwed and die.
Re: Compiled programs to keep BEGIN blocks? (was Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C ))
On Mon, Jan 14, 2002 at 04:16:49PM +, Piers Cawley wrote: > Michael G Schwern <[EMAIL PROTECTED]> writes: > > > On Mon, Jan 14, 2002 at 10:23:46AM +, Piers Cawley wrote: > >> Um... You're wrong. If you do need 'startup time' initialization then > >> you should do it in an INIT block. If I may quote from the > >> documentation: > > > > Like it or not, people put lots of init code into BEGIN blocks, if > > nothing else for backwards compatiblity with 5.005. perlcc has to > > compile real world programs. > > Deferring BEGIN blocks 'til runtime will break rather more realworld > program than it fixes I think. Where is deferring involved? -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Lord of Kwalitee! Wearer of the CPANTS and Slayer of Pseudo-hashes!
Re: Compiled programs to keep BEGIN blocks?
On Mon, Jan 14, 2002 at 06:45:05PM +0100, Rafael Garcia-Suarez wrote:
> > # ~/tmp/Bar.pm
> > package Bar;
> >
> > print "\@INC as Bar sees it\n";
> > print join "\n", @INC;
>
> Nah. You should wrap this code in a CHECK block : otherwise, in
> your example, it will be run at BEGIN-time (i.e. when the Bar module
> is use'd). That's what O.pm does.
You forget (and I forgot), B::C is encased in the perlcc wrapper
script. So what we really have is this:
print "\@INC as perlcc sees it\n";
print join "\n", @INC;
system(qq{$^X -cwle 'BEGIN { push \@INC, "bar" }'});
So perlcc can simply save the state of @INC (and whatever else B::C
might have trouble getting at) and pass that information along.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Maybe they hooked you up with one of those ass-making magazines.
-- brian d. foy as misheard by Michael G Schwern
Re: Compiled programs to keep BEGIN blocks? (was Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C ))
On Mon, Jan 14, 2002 at 11:20:43PM +0100, Rafael Garcia-Suarez wrote: > On 2002.01.14 22:27 Michael G Schwern wrote: > > B::Deparse has slowly gotten very good at figuring out BEGIN blocks > > from 'use' statements and putting them in the right places. Hard > > fought knowledge. Steal from it. > > There are still problems with pragmas. (As I was working on B::Deparse > the last few weeks, if you find new solutions, let me know.) I don't know if B::C has to worry about the same style of pragma problems as B::Deparse. ie. it doesn't have to worrying about reconstructing 'use strict' from a bunch of magic $^H twiddling opcodes. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One You can't control the universe with a jar of red pepper. http://www.goats.com/archive/981004.html
Re: Compiled programs to keep BEGIN blocks? (was Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C ))
On Mon, Jan 14, 2002 at 10:38:36PM +, Piers Cawley wrote:
> >> Deferring BEGIN blocks 'til runtime will break rather more realworld
> >> program than it fixes I think.
> >
> > Where is deferring involved?
>
> Err... it goes like this:
>
> by the main program>
>
>
>
>
>
> The compiled file gets dumped out at CHECK time as I think we said
> before. What you propose is to defer BEGIN processing to after the
> CHECK phase. So, how do you decide whether
>
> BEGIN {
> push @INC, 'bibble';
> }
>
> gets evaluated at compile time (which it should because it has far
> reaching effects about where stuff gets included from during
> compilation), or if it gets evaluated at runtime. Admittedly, this one
> is rather straightforward.
Oh, I think you misunderstand. Everything gets evaluated like normal.
BEGIN blocks run, checks, whatever. Then its all compiled and dumped.
The only difference I'm proposing is that any code in the BEGIN blocks
(mod use statements and whatnot) is also dumped. So the resulting
C code mirrors what the original was doing.
You can get at the BEGIN code via B::save_BEGINs. You can figure out
what's code and what's just a use statement. You can squelch any
output with O.pm's -qq.
What's left?
> Meanwhile we *do* have INIT blocks will do what you want without doing
> the impossible. (Well, admittedly, educating programmers might well be
> nearly impossible too, but dammit the behaviour of BEGIN blocks has
> been *documented* since before there was a Perl compiler. And the
> behaviour of INIT and CHECK blocks have also been clearly documented
> since they were interested.
>
> This really is a case of 'READ THE FSCKING MANUAL'.
Its also a case of "I'd rather not break backwards compatibility [1]
just to feed perlcc's neurosises".
There's also the factor that for all intents and purposes, Joe Average
Programmer really shouldn't have to care about the difference between
BEGIN, INIT and CHECK. In fact, they should be able to get along just
fine without ever knowing INIT and CHECK even exist. Sort of like
*foo{HASH} and the finer points of the -D switch.
Its perlcc's job to reproduce the actions of the original code to the
best of its abilities. It might turn out that its not possible. This
is, after all, an experiment.
[1] I think they were in 5.005_XX, just not documented well until 5.6.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Maybe they hooked you up with one of those ass-making magazines.
-- brian d. foy as misheard by Michael G Schwern
Re: Compiled programs to keep BEGIN blocks? (was Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C ))
On Mon, Jan 14, 2002 at 11:11:57PM +, Nicholas Clark wrote: > On Mon, Jan 14, 2002 at 10:38:36PM +, Piers Cawley wrote: > > Michael G Schwern <[EMAIL PROTECTED]> writes: > > > > > On Mon, Jan 14, 2002 at 04:16:49PM +0000, Piers Cawley wrote: > > >> Michael G Schwern <[EMAIL PROTECTED]> writes: > > > >> > Like it or not, people put lots of init code into BEGIN blocks, if > > >> > nothing else for backwards compatiblity with 5.005. perlcc has to > > >> > compile real world programs. > > > Meanwhile we *do* have INIT blocks will do what you want without doing > > the impossible. (Well, admittedly, educating programmers might well be > > nearly impossible too, but dammit the behaviour of BEGIN blocks has > > been *documented* since before there was a Perl compiler. And the > > behaviour of INIT and CHECK blocks have also been clearly documented > > since they were interested. > > > > This really is a case of 'READ THE FSCKING MANUAL'. > > I can't see that anything is going to solve what Schwern wants, becuse what > he wants is a solution backwards compatible to 5.00503 and preferably 5.004 I want 5.004_05 compatible code (or any syntacticly correct piece of Perl code) to be able to be compiled correctly (eventually) with the latest version of perlcc. If there's Perl->C translation issue as to why that's not possible, ok. But I know from a B standpoint all the information is there to handle BEGIN blocks. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Now I fight for wisdom. http://sluggy.com/d/010204.html
Re: Compiled programs to keep BEGIN blocks? (was Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C ))
On Mon, Jan 14, 2002 at 11:43:24PM +, Piers Cawley wrote:
> > What's left?
>
> What about begin blocks with side effects. How do you propose
> detecting the side effects. How do you deal with things that may
> dispatch to different subroutines depending on when they are
> evaluated? How do you deal with arrays getting initialised (and
> possible extended) twice? How, in short do you solve the halting
> problem?
A scene from Perl: The Gathering.
Piers has played the Halting Problem card your thread!
Schwern counters by taping Hitler and playing two Befuddled
Innocence cards!
;)
I don't understand. Why do we have to deal with them? Just translate
the Perl code in the BEGIN block to C , dump it and make
sure it gets run first. Right?
I think I'm missing something very vital here.
> The point is that even B::Deparse, which tries very hard to get BEGIN
> blocks right, can't do this and, according to the above extract, is
> highly unlikely to do so in the forseeable future.
Like I said, I don't expect perlcc to run perfectly Right Now, but I
do expect this to be considered a bug, not a feature. The upshot of
this is: don't prop up the perlcc tests to shield against this.
That was the original point of this thread. Somebody will come along
and fix it someday. That day might be tommorrow, dunno. Three weeks
ago perlcc was declared indefinitely dead in the water, now its alive
and kicking again. We do impossible things all the time.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
grep { ref and ref !~ /^[A-Z]+$/ } kill 9, @ARGV;
Re: Compiled programs to keep BEGIN blocks? (was Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C ))
On Tue, Jan 15, 2002 at 08:51:06AM +, Piers Cawley wrote:
> > I don't understand. Why do we have to deal with them? Just translate
> > the Perl code in the BEGIN block to C , dump it and make
> > sure it gets run first. Right?
> >
> > I think I'm missing something very vital here.
>
> Let's see if I can come up with a simple counterexample that will show
> up the problem.
>
> #!perl
> my($compile_time, $start_time);
> BEGIN {$compile_time .= localtime(time)}
>
> # Later:
>
> print "Compiled at $compile_time\n";
> print "Started at $start_time\n";
>
> ...
>
> BEGIN {$start_time .= localtime(time)}
> __END__
>
> How do you intend to distinguish between those two BEGIN blocks, one
> of which must be run at script compile time, the other of which must
> be run at (for want of a better description) INIT time? And neither of
> which can be run twice (hence the .=).
Wouldn't both of those BEGIN blocks be run at compile-time? The only
ordering I'd see is that the first one declared (ie. $compile_time) is
run before the second (ie. $start_time).
> The only thing that can make that distinction is a human being. The
> compiler can probably guess that the two blocks should only be run
> once
Guess? Its a BEGIN block, it gets run once!
Ok, there's some really fundemental breakdown of understanding here,
and I think its me. Let's step back a second. Why is anything
guessing when and how many times BEGIN blocks are run?
Is B::C literally dumping out the total state of the interpreter after
compile-time, variables and everything?!
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Paste is a waste if you're chaste,
but in this case dump a load
of goo and poo by the case in your face,
and place in your jawls like a juicy chaw,
but don't spit that shit and enjoy it all.
-- Ubergirl's beau
Re: Compiled programs to keep BEGIN blocks? (was Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C ))
On Wed, Jan 16, 2002 at 08:45:26AM +0100, Paul Johnson wrote: > The fundamental problem here is that BEGIN blocks have to run when they > are compiled. This is documented. You can try to work out whether the > BEGIN blocks can be rearranged and run at different times, but as Piers > has pointed out, this is impossible in the general case. So if the > BEGIN blocks are run at compile time, there's no point having them > around at run time. This is the raison d'?tre of INIT blocks. Ok, lemme run this by you. Here's my conception of how perlcc/B::C works. The program is compiled, the opcode tree is scanned and the appropriate C code is written for each op in the program. Just like B::Deparse scans the opcode tree and writes out Perl code. Which is why I'm having so much conceptual trouble with why BEGIN blocks would be a problem. It seems that's wrong. That what perlcc/B::C does is 'freeze' the current state of the interpreter after compilation, including the values of variables, and then spit out appropriate C code for only the post-compile opcode tree. Is this right? In which case, yes, I can see how BEGIN blocks would be troublesome. :( -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Nature is pissed. http://www.unamerican.com/
Re: Compiled programs to keep BEGIN blocks? (was Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C ))
On Wed, Jan 16, 2002 at 11:39:05AM +0100, Mattia Barbon wrote: > >It seems that's wrong. That what perlcc/B::C does is 'freeze' the > >current state of the interpreter after compilation, including the > >values of variables, and then spit out appropriate C code for only > >the post-compile opcode tree. Is this right? > > Yes. That's what makes startup time faster ( but not run time, > as you surely know ) I always thought that was recouped because you didn't have to load the interpreter and wait for Perl to compile the program and libraries to bytecode. PS I got a huge number of these warnings from compiling 'use CGI' pccF6qox.c:14873: warning: decimal constant is so large that it is unsigned pccF6qox.c:14875: warning: decimal constant is so large that it is unsigned -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One This is my sig file. Is it not nify? Worship the sig file. http://www.sluggy.com
Alternative code review ideas?
I'm revamping my How To Be Lazy tutorial for 2002 with an eye towards
making it a collection of techniques which are easy to learn, easy to
teach, easy to accept and hard to screw up. I'm stuck on code review
alternatives.
Essentially, I'm looking for a way to make sure:
Stupid mistakes in code get caught
Tests get written and have decent coverage
Code style isn't attrotious
No one programmer gets tunnel vision and cranks out a load of crap
Everyone gets some familiarity with the whole code base
Experienced programmers work with inexperienced and vice-versa.
I know of two good ways to do this, but none meets my criteria. One
is Pair Programming, the other is Mandatory, Managed Code Reviews.
Pair Programming does all the above to some extent. Its easy to
learn, easy to teach (by its very nature) and fairly hard to screw up.
Unfortunately, many people find it hard to accept, especially
management ("You mean you want two programmers doing the job of one?!")
so its unsuitable for my needs.
Mandatory, Managed Code Reviews is basically where each individual
change is reviewed by another member of the team before being
committed. Its Mandatory because *all* changes are checked (using the
honor system or something like Aegis). Its Managed because people are
assigned/take review tasks each day (again, by ad hoc or using
something like Aegis).
We used it at Blackstar (AFAIK they still do, Tony?) When it worked,
it worked great. Problem is if the daily management of the system
slipped the whole system became a detriment. Basically, left to
ourselves, we would rather code than review. So review tasks piled
up, and code couldn't be committed until it passed review. So unless
changes were reviewed promptly work would stall.
There were other problems. We tended to grab the easy reviews and
avoided the hard ones. We tended to use reviews as a crutch to find
stupid mistakes and got a bit sloppy when coding.
So if the management of the review system gets lax, the whole system
comes apart. Therefore it fails the "hard to screw up" requirement.
(You guys solve any of this, Tony?)
So I'm looking for something like the above, but that meets my
criteria of being easy to learn, teach, accept and hard to screw up.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
gleam comes to my eyes
as I combine pure water
and triticale.
-- mjd
Re: Alternative code review ideas?
On Tue, Jan 29, 2002 at 08:32:54AM +, Tony Bowden wrote: > Over time the build script got more and more elaborate as it tried to > catch more and more of these. (Mike, did you ever get your stuff finished > to catch implicit dependencies, where Module Foo didn't do a 'use Bar' > but everything worked ... for now ... because the script calling it > did...?) Module::Info implements half of that. The "what does this module use/require" bit. The "what classes/modules methods/functions does this module use" bit I know how to do, but haven't implemented it yet. It should be pretty easy. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One gigaconway: a hypothetical unit of mind expansion, so disturbing it is likely to change the fundemental nature of the universe. Some contend that gigaconway events, while rare, are much cheaper to produce than antiprotons, nuclear weapons or even XML specifications, and start at US$60,000 each. If you believe gigaconway events are indeed possible, please send your tax deductable contributions to: The Conway Fund, c/o Yet Another Society http://www.yetanother.org/ -- Ziggy
Coming soon to Module::Info...
Just got this working. Next release will have... my @isa = $mod->superclasses; my %methods = $mod->class_method_calls my @methods = $mod->object_method_calls; my @functions= $mod->function_calls; # Check for constructs which make perl hard to predict. my %methods = $mod->dynamic_method_calls; my @lines = $mod->eval_string; my @lines = $mod->gotos; my %controls = $mod->exit_via_loop_control; I'm likely also going to change the interface of packages_inside() and modules_used() to be more like subroutines so I can pack more info into it (like line numbers). Found class method call to binmode via main::STDOUT at /usr/share/perl5/CGI.pm line 182 Found class method call to binmode via main::STDIN at /usr/share/perl5/CGI.pm line 183 Found class method call to binmode via main::STDERR at /usr/share/perl5/CGI.pm line 184 Found object method call to add_parameter at /usr/share/perl5/CGI.pm line 559 Found class method call to request via Apache at /usr/share/perl5/CGI.pm line 269 Found object method call to register_cleanup at /usr/share/perl5/CGI.pm line 270 Found class method call to request via Apache at /usr/share/perl5/CGI.pm line 270 Found object method call to _reset_globals at /usr/share/perl5/CGI.pm line 273 Found object method call to init at /usr/share/perl5/CGI.pm line 274 Found object method call to new at /usr/share/perl5/CGI.pm line 329 Found object method call to _setup_symbols at /usr/share/perl5/CGI.pm line 247 Found object method call to param at /usr/share/perl5/CGI.pm line 540 Found object method call to charset at /usr/share/perl5/CGI.pm line 545 Found object method call to param at /usr/share/perl5/CGI.pm line 369 Found object method call to charset at /usr/share/perl5/CGI.pm line 371 Found object method call to charset at /usr/share/perl5/CGI.pm line 382 Found object method call to cgi_error at /usr/share/perl5/CGI.pm line 388 Found object method call to read_multipart at /usr/share/perl5/CGI.pm line 400 Found object method call to query_string at /usr/share/perl5/CGI.pm line 408 Found object method call to param at /usr/share/perl5/CGI.pm line 413 Found object method call to args at /usr/share/perl5/CGI.pm line 443 Found class method call to request via Apache at /usr/share/perl5/CGI.pm line 443 Found object method call to read_from_client at /usr/share/perl5/CGI.pm line 453 Found object method call to parse_params at /usr/share/perl5/CGI.pm line 472 Found object method call to add_parameter at /usr/share/perl5/CGI.pm line 475 Found object method call to parse_keywordlist at /usr/share/perl5/CGI.pm line 476 Found object method call to param at /usr/share/perl5/CGI.pm line 482 Found object method call to param at /usr/share/perl5/CGI.pm line 488 Found object method call to delete at /usr/share/perl5/CGI.pm line 493 Found object method call to delete at /usr/share/perl5/CGI.pm line 494 Found object method call to save_request at /usr/share/perl5/CGI.pm line 496 Found object method call to all_parameters at /usr/share/perl5/CGI.pm line 295 Found object method call to add_parameter at /usr/share/perl5/CGI.pm line 313 Found object method call to print at /usr/share/perl5/CGI.pm line 519 Found object method call to _make_tag_func at /usr/share/perl5/CGI.pm line 647 Found object method call to _setup_symbols at /usr/share/perl5/CGI.pm line 226 -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One It's Airplane Glue sniffing time!
[ANNOUNCE] Module::Info 0.11
http://www.pobox.com/~schwern/src/Module-Info-0.11.tar.gz Didn't get quite as far as I'd hoped, but I got the hard part's done. The interesting bit is you can now find every function and method call in a program (I just realized I'm not handling function calls with symbolic refs quite right, will fix), the line its on, etc see subroutines_called(). superclasses() is actually a really dirty cheat and I have to spruce it up some. Some users were reporting silent failures in the last few versions. I've made failures much more noisy so we'll see if that can be worked out. 0.11 Sat Feb 2 16:54:23 EST 2002 * Fixed B::Utils->kids * Added subroutines_called() * Added superclasses() * Added dynamic_method_calls() - Documented that it isn't just for modules. - name() can now be used to set - failures inside B::Module::Info now report their errors instead of failing silently * Added a THANKS section. 0.10 Wed Dec 12 05:40:14 EST 2001 * Windows filenames would cause subroutines() and modules_used() to choke. (Thanks to Alessandro Forghieri for the patch) -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Let me check my notes. http://www.sluggy.com
Make my function a pfunc
I wrote up a little example script using the new
Module::Info->subroutines_called. Anyone that's ever tried to use
grep to find a function call in a perl program will appreciate this.
The following finds all function/method calls to isa().
$ pfunc isa /usr/share/perl/5.6.1/*.pm
Called as function in /usr/share/perl/5.6.1/CGI.pm at line 316
Called as function in /usr/share/perl/5.6.1/CGI.pm at line 327
Called as function in /usr/share/perl/5.6.1/CGI.pm at line 397
Called as function in /usr/share/perl/5.6.1/CGI.pm at line 494
Called as function in /usr/share/perl/5.6.1/CGI.pm at line 495
Called as object method in /usr/share/perl/5.6.1/CPAN.pm at line 4957
Called as function in /usr/share/perl/5.6.1/Dumpvalue.pm at line 191
Called as function in /usr/share/perl/5.6.1/Dumpvalue.pm at line 218
Called as function in /usr/share/perl/5.6.1/Dumpvalue.pm at line 248
Called as function in /usr/share/perl/5.6.1/Dumpvalue.pm at line 251
Called as function in /usr/share/perl/5.6.1/Dumpvalue.pm at line 254
Called as object method in /usr/share/perl/5.6.1/Shell.pm at line 28
Called as object method in /usr/share/perl/5.6.1/base.pm at line 12
pfunc will be distributed with Module::Info from now on.
PS The above won't work quite right with 0.11 due to a fistful of bugs
I just fixed.
#!/usr/bin/perl -w
$| = 1;
use Module::Info;
my $func = shift;
foreach my $file (@ARGV) {
my $mod = Module::Info->new_from_file($file);
unless( $mod ) {
warn "Can't find $file\n";
next;
}
my @calls = sort { $a->{line} <=> $b->{line} }
grep { defined $_->{name} and $_->{name} eq $func }
$mod->subroutines_called;
foreach my $call (@calls) {
print "Called as $call->{type} in $file at line $call->{line}\n";
}
}
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
I knew right away that my pants and your inner child could be best friends.
[ANNOUNCE] Module::Info 0.12 bug fixes, pgrep
http://www.pobox.com/~schwern/src/Module-Info-0.12.tar.gz
Added pfunc into the dist and fixed some bugs found while writing that.
0.12 Sat Feb 2 19:41:01 EST 2002
* Added pfunc
- Now tested back to 5.004
* Fixed a bug where certain modules were being ignored
- Fixed a bug in subroutines_called() with EXPR->method()
- subroutines_called() now reports properly on function calls
with symbolic refs
0.11 Sat Feb 2 16:54:23 EST 2002
* Fixed B::Utils->kids
* Added subroutines_called()
* Added superclasses()
* Added dynamic_method_calls()
- Documented that it isn't just for modules.
- name() can now be used to set
- failures inside B::Module::Info now report their errors instead of
failing silently
* Added a THANKS section.
NAME
pfunc - grep for perl functions
SYNOPSIS
pfunc subroutine FILES...
DESCRIPTION
pfunc searches the named FILES for all calls to the given subroutine. It
will report back the file and line number each call is found on along
with what sort of call it is
functionfoo()
class methodClass->foo()
object method $obj->foo()
EXAMPLE
$ pfunc isa /usr/share/perl/5.6.1/*.pm
Called as function in /usr/share/perl/5.6.1/CGI.pm at line 316
Called as function in /usr/share/perl/5.6.1/CGI.pm at line 327
Called as function in /usr/share/perl/5.6.1/CGI.pm at line 397
Called as function in /usr/share/perl/5.6.1/CGI.pm at line 494
Called as function in /usr/share/perl/5.6.1/CGI.pm at line 495
Called as object method in /usr/share/perl/5.6.1/CPAN.pm at line 4957
Called as function in /usr/share/perl/5.6.1/Dumpvalue.pm at line 191
Called as function in /usr/share/perl/5.6.1/Dumpvalue.pm at line 218
Called as function in /usr/share/perl/5.6.1/Dumpvalue.pm at line 248
Called as function in /usr/share/perl/5.6.1/Dumpvalue.pm at line 251
Called as function in /usr/share/perl/5.6.1/Dumpvalue.pm at line 254
Called as object method in /usr/share/perl/5.6.1/Shell.pm at line 28
Called as object method in /usr/share/perl/5.6.1/base.pm at line 12
NOTES
Its not fast, but its accurate.
AUTHOR
Michael G Schwern <[EMAIL PROTECTED]>
SEE ALSO
Module::Info
NAME
Module::Info - Information about Perl modules
SYNOPSIS
use Module::Info;
my $mod = Module::Info->new_from_file('Some/Module.pm');
my $mod = Module::Info->new_from_module('Some::Module');
my $mod = Module::Info->new_from_loaded('Some::Module');
my @mods = Module::Info->all_installed('Some::Module');
my $name= $mod->name;
my $version = $mod->version;
my $dir = $mod->inc_dir;
my $file= $mod->file;
my $is_core = $mod->is_core;
# Only available in perl 5.6.1 and up.
# These do compile the module.
my @packages = $mod->packages_inside;
my @used = $mod->modules_used;
my @subs = $mod->subroutines;
my @isa = $mod->superclasses;
my @calls= $mod->subroutines_called;
# Check for constructs which make perl hard to predict.
my @methods = $mod->dynamic_method_calls;
my @lines = $mod->eval_string;*UNIMPLEMENTED*
my @lines = $mod->gotos; *UNIMPLEMENTED*
my @controls = $mod->exit_via_loop_control; *UNIMPLEMENTED*
my @unpredictables = $mod->has_unpredictables;*UNIMPLEMENTED*
DESCRIPTION
Module::Info gives you information about Perl modules without actually
loading the module. It actually isn't specific to modules and should
work on any perl code.
METHODS
Constructors
There are a few ways to specify which module you want information for.
They all return Module::Info objects.
new_from_file
my $module = Module::Info->new_from_file('path/to/Some/Module.pm');
Given a file, it will interpret this as the module you want
information about. You can also hand it a perl script.
If the file doesn't exist or isn't readable it will return false.
new_from_module
my $module = Module::Info->new_from_module('Some::Module');
my $module = Module::Info->new_from_module('Some::Module', @INC);
Given a module name, @INC will be searched and the first module
found used. This is the same module that would be loaded if you just
say "use Some::Module".
If you give your own @INC, that will be used to search instead.
new_from_loaded
my $module = Module::Info->new_from_loaded('Some::Module');
Gets information about the currently loaded version of Some::Module.
If it isn't loaded, retur
Re: Test::Builder::Tester
On Mon, Feb 04, 2002 at 01:43:30AM +, Mark Fowler wrote:
> Please excuse the roughness of this module, but get feedback early is what
> they say. For now, I've thrown it up at
>
> http://2shortplanks.com/temp/tbt
>
> And I'll let the start of the pod speak for itself:
>
> NAME
>Test::Builder::Tester - test testsuites that have been
>built with Test::Builder
>
> SYNOPSIS
>use Test::Builder::Tester tests => 1;
>use Test::More;
>
>test_out("not ok 1 - foo");
>test_err("# Failed test ($0 at line 5)");
>fail("foo");
>test_test("fail works");
>
> Useful things that I could do with feedback on:
>
> 1. Is this crack fuelled, or is this actually useful? (or has this been
> done elsewhere - e.g. is Test::Catch good enough)
Yes, very useful, thank you! Tie::Catch sucks. If you look a things
like t/fail-more.t in the Test::More test suite you'll see the
horrible things I've done to test TB's output. This is much easier.
> 2. Is Test::Builder::Tester the most sensible name for it?
Good nuff.
> 3. Um, licencing of borrowed code (see AUTHOR)
Take whatever you like. In fact, if you don't mind, I'd like to
distribute this with Test::Builder/More/Simple so I can use it to test
all that.
> 4. Does this work on older perls...I don't see any reason why not, but
> I've only tested it on 5.6.1
I'll beat on it with my battery of perls.
Only suggestion is this:
# okay, reconnect the test suite back to stdout, stderr
$t->output(\*STDOUT);
$t->failure_output(\*STDERR);
$t->todo_output(\*STDERR);
should instead be:
# okay, reconnect the test suite back to stdout, stderr
$t->output($Saved_Output);
$t->failure_output($Saved_Failure_Ouput);
$t->todo_output($Saved_Todo_Output);
where $Saved_* are saved by _start_testing. That way if the user has
set their outputs elsewhere they will be undisturbed.
The bit about no_ending() I'll have to think about.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
IMHO bugs in Perl 5 shouldn't carry over to Perl 6. (Unless, of course,
we *like* the bugs... ;)
-- Ken Fox in <[EMAIL PROTECTED]>
Re: Test::Builder::Tester
H... I thought about the no_ending() problem and basically you need to be able to access the internal list of test results and muck with it to erase the results of the captured tests. I'll put something in for that. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One "Let's face it," said bearded Rusty Simmons, opening a can after the race. "This is a good excuse to drink some beer." At 10:30 in the morning? "Well, it's past noon in Dublin," said teammate Mike [Joseph] Schwern. "It's our duty." -- "Sure, and It's a Great Day for Irish Runners" Newsday, Sunday, March 20, 1988
[ANNOUNCE] Test 1.20
http://www.pobox.com/~schwern/src/Test-1.20.tar.gz
After having it pointed out that all of Test.pm's failure diagnostics
were going to STDOUT, and thus not visible via 'make test', I've
changed it so that failure diagnostics go to STDERR so they'll always
show up.
This is similar to the way Test::More behaves (surprise).
2002-02-07 Michael G Schwern <[EMAIL PROTECTED]>
* Release 1.20
* Failure diagnostics now go to STDERR so they show up
in 'make test'.
- noted in the docs that this module is no longer being
developed.
2001-12-17 Michael G Schwern <[EMAIL PROTECTED]>
* Release 1.19
- Resetting globals for mod_perl testing (thanks to Stas Bekman)
- License change to be same as perl's
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Some like elmers glue
but it needs reapplying.
I use super glue.
-- tlk
Re: Test::Builder::Tester
On Mon, Feb 11, 2002 at 01:06:28AM +, Mark Fowler wrote:
> On Mon, 4 Feb 2002, Michael G Schwern wrote:
>
> > H... I thought about the no_ending() problem and basically you
> > need to be able to access the internal list of test results and muck
> > with it to erase the results of the captured tests.
> >
> > I'll put something in for that.
>
> Excellent, that shouldn't be to difficult to add in T::B::T. This
> shouldn't change the API, and it'd make most sense to check what version
> of Test::Builder they have installed and frob the internal list if we can,
> otherwise just default to calling no_ending. Of course, if you distribute
> it with Test::Builder then we don't need to do that (as we know they have
> a capable T::B)
>
> Speaking of that, I was wondering if you're going to distribute
> Test::Builder::Tester with Test::Builder, then it might make more sense
> that you take over maintenance of the module from that point on (so that
> everything is maintained and checked from one position.)
Oh goody, more work. ;)
I've got to think a bit about how I'm going to make the internal
results accessable.
> Anyway, meanwhile, I've been working on my test suite for GD images, and
> this means that I've got to try out Test::Builder::Tester a bit more.
>
> I soon got tired of having to manually insert line numbers into text I'm
> passing to test_err, so I've added an extra function to
> Test::Builder::Tester called line_num that (via caller) simply returns
> what line you called from plus an offset. i.e.
>
> test_out("not ok 1 - foo");
> test_err("# Failed test ($0 at line ".line_num(+1).")");
> fail("foo");
> test_test("fail works");
>
> This is now available at the same URL as before
>
> http://2shortplanks.com/temp/tbt/
>
> If there's a better way of doing this then let me know.
>
> Finally, speaking of the standard error messages that Test::Builder
> prints out: How stable are these?
Most of them are pretty stable, with the possible exception of
can_ok(). There's no guarantee they won't change, though.
> If T::B::T is testing for them then
> it might make sense to have a function that does something like
>
> test_out("not ok 1 - foo");
> test_err(fail_line(+1))
> fail("foo");
> test_test("fail works");
>
> This way if you ever change the message Test::Builder prints out for
> a standard line failure, all the test frameworks built with T::B::T
> won't break.
>
> Oh look, it's 1am again and I'm babbling.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Do you actually think about what you are saying or is it an improvisational
game of Mad Libs that you play in your head?
Re: Interactive tests?
On Wed, Feb 13, 2002 at 04:11:59PM -0500, Kirrily 'Skud' Robert wrote:
> Using Test::More, how can I intersperse stuff for user interaction? For
> instance:
>
> print "Please enter the hostname/ip for the server [localhost]: ";
> my $host = ;
> print "Please enter the admin password [default]: ";
> my $password = ;
> $agent = esmith::FormMagick::Tester->new(host => $host, password => $password);
> isa_ok($agent, 'esmith::FormMagick::Tester');
> is($agent->{password}, $password || 'default', "Set password correctly");
>
> Test::More takes control of so much stuff that my user prompts are never
> printed.
Test::Harness swallows everything that goes to STDOUT, so the user
will never see the prompts. You could print them to STDERR, but that
will rapidly get messy.
Best bet is to ask any questions *before* running the tests. In
MakeMaker terms that would be either by having Makefile.PL ask them
or by overriding test_via_harness.
{
package MY;
sub test_via_harness {
my($self, $perl, $tests) = @_;
#-> Ask your questions
#-> Dump it out to a file
$self->SUPER::test_via_harness($perl, $tests);
}
}
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Instant Cross-Platform CGI Programming in Visual Perl 5 with Object Oriented
Design in 7 Days Unleashed for Dummies Special Edition with Exclusive Java
Chapters for Developers. Year 2000 compliant, Enterprise edition and ISO9000-
certified. A Nutshell Handbook Designed For Windows 95/98/NT with a forward by
Larry "Bud" Melman. Interactive Multimedia CDROM included. 3rd revised editon,
covers Perl5.6.
Of course, it will be refered to by its simple acronym:
ICPCGIPiVP5wOODi7DU4DSEwEJC4DY2KCEedISO9000-cNHD4W9598NTLBMIMCDROM3edP5.6
Re: Interactive tests?
On Thu, Feb 14, 2002 at 03:35:43PM +, Mark Fowler wrote:
> So..sensible default values, options to change to Makefile.PL for those
> cases where you need to...and maybe then falling back to it being
> interactive?
There's the entirely undocumented but really, really useful
ExtUtils::MakeMaker::prompt() function.
use ExtUtils::MakeMaker;
my $answer = prompt("Wanna buy a monkey?", "Yes");
print "$answer\n";
which does All The Right Things:
$ perl ~/tmp/monkey.plx
Wanna buy a monkey? [Yes] No
No
$ perl ~/tmp/monkey.plx
Wanna buy a monkey? [Yes]
Yes
$ perl ~/tmp/monkey.plx < /dev/null
Wanna buy a monkey? [Yes] Yes
Yes
That last one is showing prompt() automatically accepting the default
when STDIN is not a TTY (ditto for STDOUT). It also honors
PERL_MM_USE_DEFAULT environment variable (which, oddly enough, is
documented).
Documenting it is in my TODO list. Its safe to use.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
They had applied the blinders of steam-grilled hamburgers to my eyes.
Re: VMS status @14710
On Sat, Feb 16, 2002 at 05:05:33PM -0600, Craig A. Berry wrote:
from miniperl during the build before File::Glob exists.
>
> I don't suppose there is a way to invoke at run-time the old-style
> glob (which for us is really internal, not external)?
You could instead just change that test so it only runs if File::Glob
is loaded.
if( $INC{'File/Glob.pm'} ) {
...glob('0') test...
}
else {
print "ok 8 # skip: File::Glob emulated Unixism\n";
}
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
What about MY need to be generalized and easily dismissed?
http://www.goats.com/archive/000221.html
Make Schwern poor in just 20 easy steps!
Here's the current list of untested modules. The magic number is 20. B::CC B::Disassembler B::Lint B::Stackobj B::Xref Byteloader CPAN CPAN::FirstTime Dynaloader ExtUtils::MM_NW5 ExtUtils::MM_VMS [exists, but needs some lovin'] ExtUtils::Install ExtUtils::Liblist ExtUtils::Mksymlists Net::Cmd Net::Domain Net::POP3 O Pod::Html Pod::Select -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Hey Schwern! honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk!
Re: More Test::Builder::Test stuff
On Thu, Feb 21, 2002 at 12:52:01PM +, Nicholas Clark wrote: > On Sun, Feb 17, 2002 at 02:00:06PM +, Mark Fowler wrote: > > On Sun, 17 Feb 2002, Mark Fowler wrote: > > > > > I'd really like to see that it still works on a system that > > > doesn't have Term::ANSIColor installed on it (it should turn colouring > > > into a no-op and skip tests, but I can't test that.) > > > > D'Oh! No it shouldn't. As color should work (just without colouring) on > > systems that don't have Term::ANSIColor installed then the tests shouldn't > > be skipped at all, they should be carried out to explicitly check that > > then still work without it. > > > > Code updated so that it should do just that. > > I think that if you have enough disk space you should be able to > build yourself a second perl install that doesn't have > Term::ANSIColor installed, by configuring perl to use a different > prefix and ensuring it doesn't have any of the "standard" places to > find libraries in INC. Simpler thing to do would be to create t/lib/fake/Term/ANSIColor.pm which is something like: package Term::ANSIColor; die, die, die, die, die "Can't locate Term/ANSIColor.pm in \@INC\n"; and then when you want to simulate not having Term::ANSIColor in the tests you can do: unshift @INC, 't/lib/fake'; ... and any unshielded require/use of Term::ANSIColor will explode convincingly. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One "Let's face it," said bearded Rusty Simmons, opening a can after the race. "This is a good excuse to drink some beer." At 10:30 in the morning? "Well, it's past noon in Dublin," said teammate Mike [Joseph] Schwern. "It's our duty." -- "Sure, and It's a Great Day for Irish Runners" Newsday, Sunday, March 20, 1988
Re: More Test::Builder::Test stuff
On Thu, Feb 21, 2002 at 10:05:09AM -0500, Michael G Schwern wrote: > Simpler thing to do would be to create t/lib/fake/Term/ANSIColor.pm > which is something like: > > package Term::ANSIColor; > die, die, die, die, die "Can't locate Term/ANSIColor.pm in \@INC\n"; Sorry, that should be: die die kill kill die die die kill die "Can't locate Term/ANSIColor.pm in \@INC (\@INC contains: @INC)"; :) -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Obscenity is the last resort of the illiterate, Mother Fucker -- KAL
[ANNOUNCE] Test::Inline 0.14
http://www.pobox.com/~schwern/src/Test-Inline-0.14.tar.gz 0.14 Thu Feb 28 12:38:53 EST 2002 * pod2test now provides an $Original_File * Fixed handling of "print STDERR ..." in tests * Fixed $_STDERR_ and $_STDOUT_ so they clear themselves between test blocks (bug reported by Wolfgang Weisselberg) - Some point between Test::More 0.30 and 0.33 it became unsafe to redirect STDOUT/STDERR in tests. This broke pod2test. The minimum version of Test::More has been uped (again, thanks Wolfgang) 0.13 Mon Feb 18 16:40:29 EST 2002 * pod2test now exits with 1 if it doesn't find any embedded tests This release of Test::Inline is brought to you by the letters W and M. [1] I'm actually using Test::Inline now so some long standing bugs are being fixed. $_STDERR_ and $_STDOUT_ work much better now. [1] W for Wolfgang Weisselberg and M for Mitel who's paying me to write tests. :) -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Don't worry, baby, my wrath can be pretty groovy. http://www.goats.com/archive/980804.html
Sean Burke to take over Test.pm
In an effort to decentralize the core Test:: modules, and so I have to do less work, I'm handing off maintenance of the venerable Test.pm module to one Sean Burke, KotR, POD, IPA, who has expressed a desire to extend its lifespan rather than letting me continue mummifying it. So unless someone else leaps forward and says, "YES! PLEASE GIVE ME MORE WORK BECAUSE I DON'T HAVE ENOUGH ALREADY!" I'll be transfering PAUSE ownership to Sean sometime tonite. Take it away, Sean. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One What about MY need to be generalized and easily dismissed? http://www.goats.com/archive/000221.html
[ANNOUNCE] Test::Simple/More/Builder 0.42
http://www.pobox.com/~schwern/src/Test-Simple-0.42.tar.gz Small update. Just fixing a bug in T::B->current_test() to actually make it work. Folks who need to do tests with forking and such will be pleased. 0.42 Wed Mar 6 15:00:24 EST 2002 - Setting Test::Builder->current_test() now works (see what happens when you forget to test things?) - The change in is()'s undef/'' handling in 0.34 was an API change, but I forgot to declare it as such. - The apostrophilic jihad attacks! Philip Newtons patch for grammar mistakes in the doc's. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Beef Coronary
How To Test Test Destructive Things
So here's why I just fixed that bug in Test::Builder
The situation is thus: I've got a little script that's used to
start/restart and stop the ssh daemon. I want to test that it can in
fact stop the ssh daemon. Unfortunately, I ssh'd into that machine!
So stopping it would be Bad. [1]
A TCL test engineer at TPC last year gave me a technique to handle
this. It takes advantage of Perl's ability to replace existing
functions at run-time.
The sshd-stop script basically does its work like so:
use utils;
# this calls /etc/init.d/sshd stop
serviceControl( NAME => 'sshd', ACTION => 'stop' );
# this then kills all existing connections.
killall('HUP', 'sshd');
so the plan is to literally replace serviceControl() and killall()
with stub functions that do nothing but check it got the right
arguments. So write up a little module and run the ssh-stop script
system( $^X, '-It/lib', '-Mreload_overrides', $Original_File );
is( $?, 0, 'ran myself ok' );
the clever thing there is we're loading a little module,
reload_overrides.pm, that plants our stub functions. It looks like
this...
use Test::More 'no_plan';
# Here we tell the test to not use any numbers (because there were
# probably tests output'd before us) and to not do end-of-test
# checks.
my $TB = Test::More->builder;
$TB->use_numbers(0);
$TB->no_ending(1);
first thing that's going on here is we're telling the underlying
Test::Builder object to not use numbers and don't do any extra
processing at the end of the test. This is because it will be run in
a seperate process from the test script itself.
use util;
use util::system;
we load our victims so that when the sshd-stop script goes to load
them it won't blow over our overrides.
package util;
::can_ok('util', 'serviceControl');
no warnings 'redefine';
sub serviceControl {
my(%params) = @_;
::pass('service control called');
::is( $params{NAME}, 'sshd', 'serviceControl NAME == sshd' );
::is( $params{ACTION}, 'stop', ' ACTION == stop' );
return 1;
}
so this is a simple override. First we check to make sure that
serviceControl() is already loaded. Then we tell perl to not warn us
about redefining the function.
The function itself is very simple. It just reads in the arguments
and makes sure its what we expect them to be. We assume that the real
serviceControl() works, so all we care about is how its called.
package util::system;
::can_ok('esmith::util::system', 'killall');
no warnings 'redefine';
sub killall {
my($sig, @commands) = @_;
::pass('killall called');
::is( $sig, 'HUP', ' with a HUP' );
::is( @commands,1, ' one command' );
::is( $commands[0], 'sshd', ' for sshd' );
return 1;
}
and here's the same for killall().
It has to be called with some care, making sure that we take into
account that the subprocess will be running some tests of its own to
make the test counters all work out.
# this will run 9 tests.
my $tb = Test::More->builder;
$tb->current_test($tb->current_test + 9);
system( $^X, '-It/lib', -Mreload_overrides', $Original_File );
is( $?, 0, 'ran myself ok' );
and the result looks something like this:
ok 1 - ran myself ok
ok 2 - sshd lockfile touched
ok - esmith::util->can(serviceControl)
ok - esmith::util::system->can(killall)
ok - service control called
ok - serviceControl NAME == sshd
ok -ACTION == stop
ok - killall called
ok -with a HUP
ok -one command
ok -for sshd
ok 12 - ran myself ok
ok 13 - ran myself ok
ok 14 - sshd lockfile untouched
1..14
the unnumbered tests are coming from the subprocess. They're
surrounded by the rest of the normal test script.
And that's how you can test something that's otherwise destructive.
Questions? :)
[1] Its not just stop. Its "stop with extreme prejudice". It kills
all existing connections.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Beer still cheaper than crack!
[ANNOUNCE] Test::Harness 2.02
http://www.pobox.com/~schwern/src/Test-Harness-2.02.tar.gz 2.02 Thu Mar 14 18:06:04 EST 2002 * Ken Williams fixed the long standing $^X bug. * Added HARNESS_VERBOSE * Fixed a bug where Test::Harness::Straps was considering a test that is ok but died as passing. - Added the exit and wait codes of the test to the analyze_file() results. A minor release, mostly to fix the Straps bug. Test::Harness::Straps is now in active use thanks to the Good People at Mitel Networks (see also E-Smith) and will be firming up rapidly. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One It's Tobacco time!
Re: Maintaining Archive::Tar and Archive::Zip
On Sat, Mar 16, 2002 at 12:27:27PM +0100, Andreas J. Koenig wrote:
> >>>>> On 02 Mar 2002 18:41:15 -0800, Stephen Zander <[EMAIL PROTECTED]> said:
>
> > If someone would like to send them to me, I'll get my act together a
> > little better and get a new release out.
>
> A pseudo-patch would be OK? I found that Tar.pm contains
>
> chdir $_;
>
> and
>
> chdir $cwd
> if @path;
>
> I'd like to see these guarded by something like:
>
>... or Carp::croak("Could not chdir to directory ...: $!");
>
> That would be a very high security requirement.
Its worse than that, Jim.
There currently *is* a bug in Archive::Tar about this very thing.
When unpacking DBI-1.20 I believe it was, it spewed bits of itself all
over my home directory. Why my home directory you may ask?
Because...
chdir; # Means goto $HOME
the above is documented, but...
chdir ''; # also means goto $HOME
chdir undef # this, too
these have recently been deprecated and warnings added, but that won't
be showing up unless you're using 5.7.3.
So the proper way to guard a chdir is:
sub my_chdir {
my($dir) = shift;
if( defined $dir && length $dir ) {
return chdir $dir || croak "Could not chdir to $dir";
}
else {
croak "chdir given an undefined or empty directory";
}
}
and here's a patch.
--- Tar.pm.old Thu Apr 27 18:50:15 2000
+++ Tar.pm Sat Mar 16 12:57:51 2002
@@ -1,7 +1,7 @@
package Archive::Tar;
use strict;
-use Carp qw(carp);
+use Carp qw(carp croak);
use Cwd;
use Fcntl qw(O_RDONLY O_RDWR O_WRONLY O_CREAT O_TRUNC F_DUPFD F_GETFL);
use File::Basename;
@@ -83,6 +83,17 @@
return;
}
+sub _safe_chdir {
+my($dir) = shift;
+
+if( defined $dir && length $dir ) {
+return chdir $dir || croak "Could not chdir to $dir";
+}
+else {
+croak "chdir given an undefined or empty directory";
+}
+}
+
sub error {
$error;
}
@@ -584,7 +595,7 @@
next;
}
mkdir $_, 0777 unless -d _;
- chdir $_;
+ _safe_chdir $_;
}
if ($entry->{type} == FILE) { # Ordinary file
@@ -636,7 +647,7 @@
# chmod is done last, in case it makes file readonly
# (this accomodates DOSish OSes)
chmod $entry->{mode}, $file;
-chdir $cwd
+_safe_chdir $cwd
if @path;
}
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
It's Flypaper Licking time!
Re: How to test for the absence of an infinite loop?
On Mon, Mar 18, 2002 at 02:45:33AM -0500, Mark-Jason Dominus wrote:
>
> I've just found a bug in my module. The bug results in an
> inappropriate infinite loop.
>
> Before I fix the bug, I want to write up a test case.
>
> I can reproduce the bug OK, but if I put that code into the module
> tests, and the bug isn't fixed, or comes back for some reason, then
> the test program will go into an infinite loop.
>
> The test harness doesn't seem to notice that. I don't want to go
> sticking code into my test files that might cause an infinite loop and
> hang up the test harness or the entire system.
>
> If the module were for Unix only, I would stick an 'alarm 10' at the
> top of the test program. I'm told this won't work under Win32.
>
> What's the right way to handle this?
Use alarm and skip the test if $Config{d_alarm} is false (see
t/op/alarm.t for an example). If you think the infinite loop is due
to a programming glitch, as opposed to a cross-platform issue, this
will be enough.
The only other thing I can think of is to set up a parent process
which forks off a child and kills it if its still going after 10
seconds. That gets into fork(), which is even less portable than
alarm. Checking to see if Win32 can pseudo-fork is a little more
complicated than alarm (see t/op/fork.t).
If you provide both methods you can cover Unix, Win32 and a bunch of
other platforms.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
"What's black and white and makes you duck as it goes by?"
"A nun with a spear through her head."
Re: How to test for the absence of an infinite loop?
On Mon, Mar 18, 2002 at 03:57:55AM -0500, Mark-Jason Dominus wrote:
> Actually that reminds me of another puzzle I have. My module provides
> an interface to 'flock'. What is an easy way to check that the file
> is actually being locked? I put off writing the tests because i did
> not want to fork.
I just thought of a clever way to do it without alarm! Just use
non-blocking mode.
lock_file($foo);
open(FH, $foo);
ok( !flock(FH, LOCK_NB | LOCK_EX) );
if the flock fails the file is already locked.
The traditional approaches require causing a deadlock and breaking it
with alarm.
my $start = time;
lock_file($foo);
eval {
local $SIG{ALRM} = sub { die "ALARM!\n" };
alarm 5;
lock_file($foo);
alarm 0;
};
is( $@, "ALARM\n" );
can_ok( time, '>', $start + 3, 'Locking works' );
I check both the time and the alarm for thoroughness. I have had a
few issues with this on 5.6.0 where, for some odd reason, everything
dies correctly but the "ALARM!\n" message goes to STDERR and not to
$@. I can't duplicate it outside the context of a single program, so
you might be safe.
So here's the other way. We cause a deadlock using another process
which kills itself after a certain amount of time.
my $start = time;
lock_file($foo);
system($^X, '-e', 'use Whatever; alarm 5; lock_file($foo)');
cmp_ok( time, '>', $start + 3, 'Locking works' );
again, these all rely on alarm().
> Is this mailing list the right place to ask "how do I test for X"
> questions? Or would the module-authors list be more appropriate?
This is the right place. I'm keeping track of the questions &
answers, someday there will be a FAQ.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
My lips, your breast and a whole lotta strange arguing.
How to test that flock works? (was Re: How to test for the absence of an infinite loop?)
On Mon, Mar 18, 2002 at 11:14:59AM -0500, Mark-Jason Dominus wrote:
> > I just thought of a clever way to do it without alarm!
>
> So clever, it doesn't work!
>
> > lock_file($foo);
> > open(FH, $foo);
> > ok( !flock(FH, LOCK_NB | LOCK_EX) );
>
> Seriously, on most unix systems, the following:
>
> flock(FH, LOCK_EX);
> flock(FH, LOCK_EX|LOCK_NB) or die;
>
> doe *not* die. A process is allowed to ask for (and obtain) an
> exclusive lock on a file if it already has a lock on that same file.
> There's no deadlock at all.
Oh dear, never knew that.
Ok, how about some variant on this:
BEGIN {
*CORE::GLOBAL::flock = sub (*$) {
my($fh, $flag) = @_;
$Locks{fileno $fh}++;
return flock $fh, $flag;
};
}
I'm going to have to hand-wave a bit at this point. You'll likely
have to tie any handle that goes through flock() so you can check if
it was CLOSEd or DESTROYed (and thus releases the lock).
The idea is you can know when flock() has been called, on what fileno
and with what flags, and also when locks have been implicitly released.
A variant on that might be if you already have internal _lock() and
_unlock() functions.
{
my $orig_lock = \&Your::Module::_lock;
my $orig_unlock = \&Your::Module::_unlock;
no warnings 'redefine';
sub Your::Module::_lock {
my($file) = @_;
$Locks{$file}++;
goto &$orig_lock;
}
sub Your::Module::_unlock {
my($file) = @_;
$Locks{$file}--;
goto &$orig_lock;
}
do_something_that_should_result_in_a_lock($file);
is( $Locks{$file}, 1 );
...whatever else...
*Your::Module::lock = $orig_lock;
*Your::Module::unlock = $orig_unlock;
}
Sorry I can't be more specific.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Realize this, sweetheart, I'm squeezing my poodle.
Re: How to test for the absence of an infinite loop?
On Mon, Mar 18, 2002 at 02:14:23PM -0700, Sean M. Burke wrote:
> At 03:26 2002-03-18 -0500, Michael G Schwern wrote:
> >[...]Use alarm and skip the test if $Config{d_alarm} is false (see
> >t/op/alarm.t for an example). If you think the infinite loop is due
> >to a programming glitch, as opposed to a cross-platform issue, this
> >will be enough.
>
> Ya know, for a while I've wished there were a rather tidier to way to ask
> if something were implemented. Like perl->can_alarm, via a class "perl"
> that just has a clever AUTOLOAD for these things.
Someday.
*mumble* wild ideas about OS::Spec, File::System::Spec *mumble*
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
my mother once said
"never eat paste my darling"
would that I heeded
-- stimps
Re: Test::Harness Conditional Test Execution
On Mon, Mar 25, 2002 at 04:35:52PM +0900, Curt Sampson wrote: > I'm setting a unit testing system for a pile of code right now which > is going to expand into hundreds of tests. I've currently got a simple > program that finds all of the tests in the system and hands this list to > Test::Harness to be run. > > However, I'd like to be able to do two things: > > 1. Run the tests in dependency order. That is, if module A uses > module B, the tests for module B should be executed before those for > module A. Test::Harness will run the files in whatever order you give it to them. So assuming a single module's sanity tests are in a single file you can simply feed them in in a rough dependency order. > 2. Skip test of code where dependencies have been tested and found > to be failing. For example, if the test for the database connection > module fails, nothing that uses that module should have its test > run. (The tests should of course be reported as skipped.) Not really a Test::Harness thing, it's up to your test program to do this. Test::More has facilities to skip blocks of tests or whole test files. They're explained in the Test::Tutorial. > This should make it easier to fix problems because we'll see right away > where we need to start fixing things, and we won't have to go through > reams of test failures to find the one low level module failure that > caused them all. > > I'm not very familiar with Test::Harness usage, and I'm wondering > if someone could suggest a good way of doing this. I've looked at > examples/mini_harness.plx; is using those private methods really > the suggested way to go about things? No. It uses an undocumented, experimental callback interface and some private formatting functions from Test::Harness which I'm not quite sure yet how to move into Straps. mini_harness is just a proof-of-concept to see if I could reimplement most of Test::Harness's interface. You can use the callback interface, but it's not stable and is subject to change. In fact, it probably will. I still encourage people to use it. > Also, from looking at the code, I get the impression that analyze_file > is supposed to run the perl file given to it as an argument. But > the docs say otherwise: > > Like "analyze", but it reads from the given $test_file. > > Well, analyze reads test results, so presumbly the documentation > is saying that this is supposed to be a file containing the test > results, not the test code. Hmmm. Nope. Your original impression is correct. Docs are just poorly worded. Just touched it up. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One If you have to shoot, shoot! Don't talk. -- Tuco, "The Good, The Bad And The Ugly"
Re: Test::Harness Conditional Test Execution
On Tue, Mar 26, 2002 at 01:47:38PM +0900, Curt Sampson wrote: > On Mon, 25 Mar 2002, Michael G Schwern wrote: > > > > 2. Skip test of code where dependencies have been tested and found > > > to be failing. For example, if the test for the database connection > > > module fails, nothing that uses that module should have its test > > > run. (The tests should of course be reported as skipped.) > > > > Not really a Test::Harness thing, it's up to your test program to do > > this. Test::More has facilities to skip blocks of tests or whole test > > files. They're explained in the Test::Tutorial. > > Hmm. So you're saying that I should modify my tests to skip themselves > when they get information that a module they depend on has failed > its tests? How do you propose I get that information to the test? You can't. Not easily. About all you can do is abort the whole suite of tests using the "Bail Out" feature of Test::Harness should a Really Important Thing fail. print "Bail out! Database connection failed\n"; and Test::Harness won't run any further test scripts. Anything of a finer granularity rapidly gets difficult. > > You can use the callback interface, but it's not stable and is subject > > to change. In fact, it probably will. I still encourage people to > > use it. > > Well, since I need it for my current method of working, I'll just > use it and be aware that it will change. Make sure to give me any feedback about it to I can expand it according to people's needs. I'll try to at least document it next release. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One GOD made us funky!
Re: Test::Builder bug
On Sat, Mar 30, 2002 at 05:33:55PM -0600, Dave Rolsky wrote:
> The changelog says this:
>
> 0.42 Wed Mar 6 15:00:24 EST 2002
> - Setting Test::Builder->current_test() now works (see what happens
> when you forget to test things?)
>
> But if I do this:
>
> perl -MTest::Builder -e 'Test::Builder->new->current_test(10)'
>
> it still blows chunks.
$ perl -Ilib -MTest::Builder -e 'Test::Builder->new->current_test(10)'
WHOA! Somehow your tests ran without a plan!
This should never happen! Please contact the author immediately!
END failed--call queue aborted.
which is only sort of right. The above code should result in a
failure, since you forgot to plan. However, it should not result in a
whoa.
Not sure how to handle this. It should result in an integrity check
failure, since there was no plan, but it should not think its an
internal inconsistency caused by a Test::Builder bug.
Simplest thing to do would be for current_test to disallow you
from changing it unless you have a plan, like ok() does...
$ perl -Ilib -MTest::Builder -e 'Test::Builder->new->current_test(10)'
Can't change the current test number without a plan! at -e line 1
> Patch below.
Doesn't seem to have any effect on the code above, but it does have an
effect on this:
$ perl -Ilib -MTest::Builder -e '$tb=Test::Builder->new; $tb->plan('no_plan');
$tb->current_test(10)'
Modification of non-creatable array value attempted, subscript -1 at
lib/Test/Builder.pm line 948.
WHOA! Somehow you got a different number of results than tests ran!
This should never happen! Please contact the author immediately!
END failed--call queue aborted.
which will result in this in 0.43:
$ perl -Ilib -MTest::Builder -e '$tb=Test::Builder->new; $tb->plan('no_plan');
$tb->current_test(10)'
1..10
Attached is a patch to 0.42 which has been applied to fix all this.
> houseabsolute:/usr/local/share/perl/5.6.1/Test> diff -u
> /root/.cpan/build/Test-Simple-0.42/lib/Test/Builder.pm Builder.pm
> --- /root/.cpan/build/Test-Simple-0.42/lib/Test/Builder.pmWed Mar 6
> 14:14:58 2002
> +++ Builder.pmSat Mar 30 17:29:42 2002
> @@ -935,7 +935,8 @@
> if( defined $num ) {
> $Curr_Test = $num;
> if( $num > @Test_Results ) {
> -for ($#Test_Results..$num-1) {
> + my $start = @Test_Results ? $#Test_Results : 0;
> +for ($start..$num-1) {
> $Test_Results[$_] = 1;
> }
> }
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
I was *meant* to mount your donuts.
--- Changes 6 Mar 2002 20:24:57 - 1.30
+++ Changes 31 Mar 2002 03:37:01 - 1.31
@@ -1,5 +1,9 @@
Revision history for Perl extension Test::Simple
+0.43
+- TB->current_test() still not working when no tests were run via
+ TB itself. Fixed by Dave Rolsky.
+
0.42 Wed Mar 6 15:00:24 EST 2002
- Setting Test::Builder->current_test() now works (see what happens
when you forget to test things?)
--- MANIFEST19 Dec 2001 23:31:20 - 1.18
+++ MANIFEST31 Mar 2002 03:35:38 - 1.19
@@ -10,6 +10,7 @@
t/Builder.t
t/More.t
t/buffer.t
+t/curr_test.t
t/diag.t
t/exit.t
t/extra.t
--- lib/Test/Builder.pm 6 Mar 2002 20:23:23 - 1.15
+++ lib/Test/Builder.pm 31 Mar 2002 03:36:30 - 1.16
@@ -8,7 +8,7 @@
use strict;
use vars qw($VERSION $CLASS);
-$VERSION = '0.12';
+$VERSION = '0.13';
$CLASS = __PACKAGE__;
my $IsVMS = $^O eq 'VMS';
@@ -239,7 +239,8 @@
my($self, $test, $name) = @_;
unless( $Have_Plan ) {
-die "You tried to run a test without a plan! Gotta have a plan.\n";
+require Carp;
+Carp::croak("You tried to run a test without a plan! Gotta have a plan.");
}
$Curr_Test++;
@@ -564,7 +565,8 @@
$why ||= '';
unless( $Have_Plan ) {
-die "You tried to run tests without a plan! Gotta have a plan.\n";
+require Carp;
+Carp::croak("You tried to run tests without a plan! Gotta have a plan.");
}
$Curr_Test++;
@@ -598,7 +600,8 @@
$why ||= '';
unless( $Have_Plan ) {
-die "You tried to run tests without a plan! Gotta have a plan.\n";
+require Carp;
+Carp::croak("You tried to run tests without a plan! Gotta have a plan.");
}
$Curr_Test++;
@@ -933,9 +936,16 @@
my($self, $num) = @_;
if( defined $num ) {
+
+unless( $Have_Plan ) {
+require Carp;
+Carp::croak("Can't change the current test numb
Re: Test::Builder and Test::More change requests
On Thu, Apr 04, 2002 at 12:01:45PM +0100, Mark Fowler wrote:
> Firstly, is there anyway we could get Test::Builder's diag (and thus
> Test::More's) diag to return false not true like it currently does.
>
> This would then allow me to write simply
>
> sub is_reversed
> {
> return $Tester->ok($_[0] eq reverse($_[1]))
>or $Tester->diag("The reverse of '$_[0]' is '".reversed($_[0]).
> "' not '$_[1]' as expected")
> }
>
> rather than having to do the horrible "&& 0" at the end to ensure that
> the method returns the correct truth (otherwise is_reversed will return
> true no matter what is called)
Sensible. Done. If anyone asks, it's your fault.
> Secondly, I was wondering about eq_set in Test::More.
>
> ok(eq_set([1,1,1],[1]));
>
> fails, where really it should work as sets don't care about reoccurring
> elements. Should this be 'eq_bag' instead?
eq_set() is really just because I got sick of writing:
eq_array([sort @something], [sort @something_else]);
wasn't really thinking about Set Theory at the time. So yes, eq_set()
would probably be better as eq_bag() or something. But we can't
change the name now.
However, the eq_* functions are largely discouraged because they can't
produce intellegent diagnostics. If any new complex data structure
comparison utilites were added I'd rather go the is_deeply() route.
And all that stuff needs to be moved into Test::Builder anyway. Can
'o worms.
As for Test::More, don't think I'll be taking any new functions. The
interface is already too big. But the deep data structure
functionality isn't really complete.
I'd encourage you to write a Test::Builder based module that does more
complete set & complex data testing. Either talk to Barrie about
adding it to Test::Differences or start a new module. Test::Set,
Test::Data::Deep, etc...
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Lesbian lovers
return to fourth grade slogans
EAT SOME PASTE, they cry
sobbing lesbian
excluded from the party
allergic to wheat
-- mjd
Re: Comparing Data Structures Slopply
On Tue, Apr 09, 2002 at 03:26:21PM +0100, Mark Fowler wrote: > There's a lot of other problems like that. So I was thinking of writing > Test::Sloppy (aka Test::Fuzzy, aka...) What would it do? (I can show you lots of sloppy tests if you like. :) -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Here's some scholarly-ass opinions...
Re: Comparing Data Structures Slopply
On Tue, Apr 09, 2002 at 05:02:32PM +0100, Mark Fowler wrote: > On Tue, 9 Apr 2002, Michael G Schwern wrote: > > > On Tue, Apr 09, 2002 at 03:26:21PM +0100, Mark Fowler wrote: > > > There's a lot of other problems like that. So I was thinking of writing > > > Test::Sloppy (aka Test::Fuzzy, aka...) > > > > What would it do? > > > > (I can show you lots of sloppy tests if you like. :) > > Sorry, maybe it wasn't clear from the example. sort of like eq_set meets > is_deeply. I think "Sloppy" or "Fuzzy" is the wrong term for this. It implies you're doing some sort of approximate matching like String::Approx. Sounds like you just want better tools for testing multi-level data structures. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Don't ask me lady, I live in beer.
Re: Test::Exception... comments?
On Tue, Apr 09, 2002 at 10:05:49PM +0100, Adrian Howard wrote:
> Hi all,
>
> I've been refactoring a bunch of old tests with Test::More and some
> convenience routines for testing exceptions dropped out (along with some
> class base testing and mock object modules which still need cleaning up into
> something sane.)
>
> dies_ok BLOCK TEST_NAME
> Tests to see that BLOCK exits by dying, rather than by exiting
> normally. For example:
>
> dies_ok { div(1, 0) } 'divide by zero detected';
You probably want to guarantee that $@ will be how it died so you can do:
dies_ok { div(1,0) } 'div by zero';
like( $@, qr/^Illegal division by zero/ );
Even though you can use throws_ok(), the dies_ok() + $@ combo is more
flexible more processing than just a regex needs to be done on $@.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Death follows me like a wee followey thing.
-- Quakeman
