Re: Changing T::B behavior (was Re: And for the mod_perl folks... Test::Builder->reset)

On Wed, 13 Nov 2002 15:54:44 +, Michael G Schwern wrote: > The problem there is the case where you want to override behaviors but still > keep state between the two objects. So things like the test counter and > test details would have to be preserved. I guess this is what chro

Re: Literal Values

On Tue, 12 Nov 2002 17:00:17 +, Dave Whipp wrote: (cross-posting to perl.qa for other perspectives) > When I look at this, I find myself wanting to separate the control from the > data. Here's an alternative: > > my @input = qw( 4.5 0.0 13.12343 ); > my @output = qw( 4.5 0.0 13.1234

Re: And for the mod_perl folks... Test::Builder->reset

On Monday 11 November 2002 14:40, Michael G Schwern wrote: > > We *could* add a method called really_create_a_new_builder() that doesn't > > have the singleton properties, but what problem does that solve? As long > > as we're stuck with test numbers, we have to try not to confuse > > Test::Harne

Re: And for the mod_perl folks... Test::Builder->reset

On Mon, 11 Nov 2002 02:24:23 +, Michael G Schwern wrote: > Also, for those who aren't happy with the fact that Test::Builder is a hard > singleton with its state held in a bunch of file-scoped lexicals (hard to > debug) reset() made me collect together all those state variables in one > point

Re: Test::Builder->level

On Sun, 10 Nov 2002 23:10:40 +, Michael G Schwern wrote: > At YAPC::Europe there was some discussion about Test::Builder->level, > $Test::Builder::Level and the fact that they don't really work well as > implemented. I know we reached some sort of consensus about how to do it > better, but I'

Re: [ANNOUNCE] tv (Test::Verbose 0.001)

) $TODO, as long as there's also a reference to > Chromatic to actually get a round tuit. That still gets my tests written for > me with maximal laziness] Then who'll write the tests for me? There are only so many Autrijuses, Tatsuhikos, and petdances to go around. -- c

Re: Test::Class - comments wanted

On Mon, 14 Oct 2002 14:46:38 -0700, Michael G Schwern wrote: > OTOH, my thinking recently is that the explicit plan has become obsolescent. > [1] > > The explicit plan protects against: > > 1. Your test dying. > 2. Your test not printing tests to STDOUT > 3. Exiting early via exit(). > > #1 an

Re: Help spreading Test

On Sunday 28 July 2002 02:52, Johan Vromans wrote: > > On Fri, 26 Jul 2002 13:19:51 -0700, Johan Vromans wrote: > > This idea appeals to me, but I have thought of two drawbacks. The first > > is minor, and it's that I don't think Test::Builder should have special > > logic for installation. It

[PATCH MakeMaker.pm] Add documentation for ExtUtils::MakeMaker::prompt()

Hi, Here's a rough cut at documentation for the hitherto rumored prompt() function. Suggestions welcome. -- c diff -ur ExtUtils-MakeMaker-6.03~/lib/ExtUtils/MakeMaker.pm ExtUtils-MakeMaker-6.03/lib/ExtUtils/MakeMaker.pm --- ExtUtils-MakeMaker-6.03~/lib/ExtUtils/MakeMaker.pm Wed Jun 19 14:07:3

Re: Strange interactions...

On Wed, 14 Aug 2002 07:47:31 -0700, Piers Cawley wrote: > Further to this, here's a failing test script: > > use Test::More tests => 2 > > sub Bar::DESTROY { eval { 1 } } > > eval { my $obj = bless {}, 'Foo'; >die "Deliberately" }; > like $@, qr/Deliberately/, "This passes"; > > eval

Re: [perl #15479] perl 5.8.0 segfault

On Wed, 31 Jul 2002 04:30:12 -0700, Nicholas Clark wrote: > On Wed, Jul 31, 2002 at 01:20:25PM +0200, Rafael Garcia-Suarez wrote: >> Wasn't there a .t file to run separate perl interpreters and test for core >> dumps ? > I keep forgetting that I need to remember to ask this. Is there a FAQ fo

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

On Wednesday 31 July 2002 12:39, Michael G Schwern wrote: > > This patch captures messages sent through diag() and stores them in the > > diagnostic array. Now all of the information the tests generate is > > available for later inspection. > Dude, where's my patch? Did I completely miss it?

Re: Help spreading Test

On Fri, 26 Jul 2002 13:19:51 -0700, Johan Vromans wrote: > One of the problems I have with using Test::Builder is that I want to > distribute packages to systems that do not (necessarily) have a decent version > of Test::* installed. Now it is easy to include a copy of a suitable version > of Tes

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

This patch captures messages sent through diag() and stores them in the diagnostic array. Now all of the information the tests generate is available for later inspection. It made the most sense to attach diagnostics to the previous test data. The documentation suggests a construct something lik

Re: [PATCH Test::More] Allow isa_ok( $classname, $parent )

On Saturday 06 July 2002 18:41, Michael G Schwern wrote: > The purpose of isa_ok() is two fold: > Check that a scalar contains an object > Check that object is of the right class > and it only exists because it's a very common test and you have to do the > above in several steps to get

[PATCH Test::Simple] Implement Test::Builder::details()

Since Test::Builder::details() is marked UNIMPLMENTED in 0.45, it seemed like a useful method to add. This patch does so, with the appropriate tests in t/Builder.t. It works as per my understanding of the Test::Builder POD. I very nearly updated the copyright notice in Test::Builder, while I wa

[PATCH Test::More] Allow isa_ok( $classname, $parent )

Here's a patch to the Test::Simple 0.45 distribution to make isa_ok() work with class names, not just objects. It tries to respect custom isa() methods, as well. -- c diff -ur Test-Simple-0.45.old/lib/Test/More.pm Test-Simple-0.45/lib/Test/More.pm --- Test-Simple-0.45.old/lib/Test/More.pm

Re: RFC: Test::Warn

On Thu, 27 Jun 2002 07:32:31 -0700, Janek Schleicher wrote: > I couldn't find a module doing this job on CPAN, so I'm ready to write a > Test::Warn module. This is something I'd use. > I'd like to know what you are thinking about ?, especially: > - is it already on CPAN > - Name: Test::Warn /

Re: Pondering Test::Depend

On Saturday 08 June 2002 17:32, Adrian Howard wrote: > I found that, once you have a moderately complex system, it's hard to > determine whether changes you are being warned about are going to be an > issue (beyond simple things like method renaming). I spent too much time > looking at the code,

Re: Pondering Test::Depend

On Saturday 08 June 2002 11:39, Michael G Schwern wrote: > It gives you three levels of uncertainy. If Bar.pm is being actively > developed, the tests and version number will be changing constantly and the > dependency check will also be constantly "failing", causing it to be > ignored, or only

Re: Pondering Test::Depend

On Saturday 08 June 2002 11:02, Michael G Schwern wrote: > > If this dependency information changes, it'll fail a test (or maybe warn) > > because there's a potential interface change that Bar.pm may need to > > know. > It looks interesting up to this point. Basically, everytime Bar.pm is > tou

Pondering Test::Depend

I'm a big fan of testing units in isolation. It's easier, faster, and tends to more comprehensive and detailed tests. The problem is, if the unit being tested has a legitimate dependency on another unit in the suite, isolation testing cannot identify interface changes. This has bothered me for

Re: [REPATCH MANIFEST ext/B/t/o.t] Add tests for O

On Friday 10 May 2002 01:10, [EMAIL PROTECTED] wrote: > Move these use() after the BEGIN (so you get the correct @INC). > Shouldn't you mkdir ./lib/B before this ? > Tests 7 and 8 will fail without perlio, thus you should > skip them (see the BUGS section is O.pm's pod). You guys are a lot pic

Re: [REPATCH MANIFEST ext/B/t/o.t] Add tests for O

On Thursday 09 May 2002 22:07, Jarkko Hietaniemi wrote: > On Thu, May 09, 2002 at 10:00:10PM -0700, chromatic wrote: > > + 1 while unlink('lib/B/success.pm'); > I suggest a VMS test drive account :-) The password's around here somewhere. Perhaps preferable,

[REPATCH MANIFEST ext/B/t/o.t] Add tests for O

Let's try this then: --- MANIFEST~ Thu May 9 19:04:21 2002 +++ MANIFESTThu May 9 19:06:06 2002 @@ -88,6 +88,7 @@ ext/B/Makefile.PL Compiler backend makefile writer ext/B/NOTESCompiler backend notes ext/B/O.pm Compiler front-end module (-MO=...) +ext/B/t/o.t

Re: [PATCH MANIFEST ext/B/t/o.t] Add tests for O

On Thursday 09 May 2002 21:32, Jarkko Hietaniemi wrote: > > +open(OUT, '>lib/B/success.pm') or skip_all( 'Cannot write fake backend > > module'); > Unportable filename. Would File::Spec help? > > +@lines = split(/\n/, runperl( args => \@args, stderr => 1 ) ); > Portable to split on /\n/? Looki

[PATCH MANIFEST ext/B/t/o.t] Add tests for O

Just when you thought it was safe to smoke Perl... I'm also working on tests for CPAN::FirstTime, though they may require a bit of reorganization to do it right. It'll likely make the code smaller and more flexible too. -- c --- MANIFEST~ Thu May 9 19:04:21 2002 +++ MANIFESTThu May 9 19

Re: Test::MockObject 0.03

On Sunday 28 April 2002 02:00, Tatsuhiko Miyagawa wrote: > Here's a patch > * pass tests in 5.005_03 > * can() should return subref instead of just 1 Thanks, applied! I also added a test to prevent that can() thinko from reoccurring. > Seems interesting. But I prefer a direct way to define M

Test::MockObject 0.03

nd at: http://wgz.org/chromatic/perl/Test-MockObject.tar.gz Suggestions, comments, and patches welcome. -- c

[PATCH] Make Test::More::can_ok() use objects, not just classes

I'm writing a new module called Test::MockObject. It has a test that reads: $mock->add('foo'); can_ok( $mock, 'foo' ); Test::MockObject has a custom can() method, which checks instance data to decide if the object can handle the method: sub can { my ($se

[PATCH lib/Test/Builder.pm t/output.t] "Escape" newlines in test output

I'm not dead or pining for the fjords. This was discussed at the end of January on p5p, and Benjamin Goldberg suggested the regexp solution that appears here. -- c diff -ur Test-Simple-0.43old/lib/Test/Builder.pm Test-Simple-0.43/lib/Test/Builder.pm --- Test-Simple-0.43old/lib/Test/Builder.pm

[PROPOSED PATCH] Sanitize Test::Builder Output (was Re: [ PATCH ] Re: Smoke 14406 /pro/3gl/CPAN/perl-current)

On Sunday 27 January 2002 09:31, Jarkko Hietaniemi wrote: > Thanks, applied. Check to skip() that the message ends sanely? Here's an approach with a test case that demonstrates the problem. -- c --- lib/Test/~Builder.pm Sun Jan 27 12:09:35 2002 +++ lib/Test/Builder.pm Sun Jan 27 12:15:52 20

[REPATCH MANIFEST, ext/re/re.t] Tests for re pragma

Thanks to Benjamin Goldberg for finding a logic error in the previous version. This also patches. Someone more familiar with regex tokens ought to make sure they're deparsed correctly. Never been a Nick, -- c --- ~MANIFEST Sat Dec 15 23:53:50 2001 +++ MANIFESTSat Dec 15 23:54:17 2001 @@

[PATCH MANIFEST, lib/ExtUtils/t/MM_OS2.t] Tests for ExtUtils::MM_OS2

These tests all pass, though I don't have an OS2 box. I don't forsee any difficulty there, though it would be good to check. -- c --- ~MANIFEST Thu Dec 20 16:06:11 2001 +++ MANIFESTThu Dec 20 16:06:26 2001 @@ -937,6 +937,7 @@ lib/ExtUtils/MM_Cygwin.pm MakeMaker methods for Cygwin l

[PATCH] Re: emitting messages in Test::*

On Wed, 19 Dec 2001 05:12:05 -0700, Michael G Schwern wrote: > 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, T

Re: is() with arbitrary comparisions

On Wed, 19 Dec 2001 10:04:17 -0700, Tels wrote: > First, ok() is no no longer ok(), but is now is(), because ok() is no longer > ok to use with ok($this,$that); but is() is ok with $that. And then there is > isnt(), isn't it? Not to speak of the use of can_ok(), which you can use, ok? > isnt() $t

Re: v0.3 [Was: CPAN Upload: R/RB/RBS/Test-Differences-0.2.tar.gz]

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 qu

Re: Untested modules update: There's more than we thought

Hello again Gerrit, You know, I didn't put the MOST important line in the block. Here's a better patch. I blame Jeffrey Friedl. :) Any better? -- c --- lib/ExtUtils/~MM_Cygwin.t Sun Dec 16 11:02:04 2001 +++ lib/ExtUtils/MM_Cygwin.t Sun Dec 16 19:59:44 2001 @@ -69,12 +69,17 @@ $args->{

Re: Untested modules update: There's more than we thought

On Sun, 16 Dec 2001 19:30:18 -0700, Benjamin Goldberg wrote: > 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. Agreed. You have my

Re: Untested modules update: There's more than we thought

On Sunday 16 December 2001 02:10, Gerrit P. Haase wrote: Thanks for the report. > ../lib/ExtUtils/MM_Cygwin.# Failed test > (../lib/ExtUtils/MM_Cygwin.t at line 73) # undef > # doesn't match '(?-xism:could not locate your pod2man)' > # Failed test (../li

Re: [PATCH MANIFEST, ext/re.t] Basic tests for re.pm

On Sun, 16 Dec 2001 00:43:07 -0700, Benjamin Goldberg wrote: > chromatic wrote: >> +re->unimport('taint'); >> +isnt( $^H & 0x0010, 1, 'unimport should clear bits in $^H when >> requested' ); +re->unimport('eval'); >> +isnt

[PATCH MANIFEST, ext/re.t] Basic tests for re.pm

Here are tests for everything but the 'debug' subpragma of the re pragma. That'll take a bit more scary regex-fu than I have at the moment. Anyone who is daring enough to change re.pm, re.xs, or re.c, though, now has no excuse for improving the tests. -- c --- ~MANIFEST Sat Dec 15 23:53:50 20

[PATCH MANIFEST, lib/ExtUtils/Installed.t] Add tests for ExtUtils::Installed

This passes all tests, gets the MANIFEST patch right for once, and shouldn't have weird sorting bugs on EBCDIC platforms. Cross your fingers. -- c --- ~MANIFEST Sat Dec 15 23:17:25 2001 +++ MANIFESTSat Dec 15 23:17:42 2001 @@ -906,6 +906,7 @@ lib/ExtUtils/inst Give informati

Re: v0.3 [Was: CPAN Upload: R/RB/RBS/Test-Differences-0.2.tar.gz]

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

Re: Untested modules update: There's more than we thought

On Fri, 14 Dec 2001 15:18:43 -0700, Michael G Schwern wrote: > ExtUtils::MM_Cygwin Here's a test for that. It could use someone on Cygwin testing it. Tels said he would, but apparently got busy. -- c --- ~MANIFEST Sun Nov 25 19:50:46 2001 +++ MANIFESTSun Nov 25 21:08:01 2001 @@ -930,6

Re: Tentative Term::ReadLine patch/test

On Sat, 08 Dec 2001 12:04:27 -0700, Richard Clamp wrote: > Does it look like I'm heading down the right road with this? If so let me > know and I'll submit it to p5p for applying to blead. +BEGIN { +chdir 't' if -d 't'; + +if ( $ENV{PERL_CORE} ) { +@INC = '../lib'; +} +}

Re: [REPATCH MANIFEST lib/ExtUtils/MM_Cygwin.t] use more 'Schwernishness';

On Sunday 25 November 2001 22:31, Michael G Schwern wrote: > > Porta-paranoia. cflags() and canonpath() are delegated to it. This may > > be why File::Spec was commingled. > Now wait a second, this means you're not actually testing what > ExtUtils::MM_Cygwin->catfile() and cflags() and perl_sc

[REPATCH MANIFEST lib/ExtUtils/MM_Cygwin.t] use more 'Schwernishness';

On Sunday 25 November 2001 21:38, Michael G Schwern wrote: > > Indeed it is. Never patch while cursing the heavy hand of George Lucas. > Hard to code while beating the hell out of your television, I know the > feeling. Television? He's playing congas two doors down. Noisy old goat... > +# te

Re: [PATCH MANIFEST lib/ExtUtils/MM_Cygwin.t] Add tests for ExtUtils::MM_Cygwin

On Sunday 25 November 2001 20:47, Michael G Schwern wrote: > $ENV{'ExtUtils/MM_Unix.pm'} ?? Maybe this supposed to be %INC? Indeed it is. Never patch while cursing the heavy hand of George Lucas. > You should be playing with MM objects instead. ExtUtils::MM_Cygwin > will handle setting @MM::

[PATCH MANIFEST lib/ExtUtils/MM_Cygwin.t] Add tests for ExtUtils::MM_Cygwin

Here's tests for ExtUtils::MM_Cygwin. They're skipped on all platforms where $^O does not match /cygwin/i. The tests out to pass just about everywhere anyway. It would be good for someone with Cygwin to test them, though. -- c --- ~MANIFEST Sun Nov 25 19:50:46 2001 +++ MANIFESTSun Nov 2

Re: is(), undef, '' and 0 (was Re: [PATCH lib/DB.pm MANIFEST lib/DB.t] Add Tests for DB.pm)

On Friday 23 November 2001 15:59, you wrote: > On Fri, Nov 23, 2001 at 03:32:41PM -0700, chromatic wrote: > > + is( DB::DB(), undef, 'DB::DB() should return undef if $DB::ready is > > false'); > > Crap, this doesn't quite work in the general case. > >

[PATCH lib/DB.pm MANIFEST lib/DB.t] Add Tests for DB.pm

Here's a bunch of tests for DB.pm. Some bits aren't easily testable, and there's room for someone more knowledgeable or clever to come along to improve them even more. In the process of writing these tests, I patched one little thing in DB.pm, per the comment. With the patch, all pass. -- c -

Re: Dusting out vms/test.com

In article , "Craig A. Berry" <[EMAIL PROTECTED]> wrote: > BTW, when running tests you're generally in the t directory, aren't you, so > wouldn't it just be "op/my_stash.t"? Not necessarily. Lots of tests start with: BEGIN { chdir 't

Re: libnet-1.09

In article <[EMAIL PROTECTED]>, "H . Merijn Brand" <[EMAIL PROTECTED]> wrote: > HP-UX 10.20: > > k1:/pro/3gl/CPAN/libnet-1.09 119 > perl -Iblib/arch -Iblib/lib t/config.t > 1..10 > not ok 4 # ... should return -1 without a valid hostname Got: '0' Expected: > '-1' > main t/config.t 2

Re: [PATCH lib/Net/Config.pm, MANIFEST, t/lib/Mock/Socket.pm, lib/Net/Config.t] Add Tests for Net::Config

On Monday 22 October 2001 14:13, Graham Barr wrote: > > I understood that as Graham being unsure about using Test::More in the > > tests. > Actually I was refering to Mock::Socket Would you be amenable to a patch that moves that into the .t file? There's no technical reason it has to be a modu

Re: [PATCH lib/Net/Config.pm, MANIFEST, t/lib/Mock/Socket.pm, lib/Net/Config.t] Add Tests for Net::Config

On Monday 22 October 2001 14:10, Michael G Schwern wrote: > I can understand this. We should be patching the CPAN libnet. In progress. > > So if a test depends on a module in the core it should check that > > the module is avaliable, so that the test is skipped with older > > perl releases. >

Re: [REPATCH installhtml] Re: installhtml needs a good beating out

In article <[EMAIL PROTECTED]>, "Benjamin Goldberg" <[EMAIL PROTECTED]> wrote: > Chromatic wrote: > [snip] >> sub parse_command_line { >> -usage() if defined $opt_help; >> -$opt_help = "";# make -w shut up +usa

[PROPOSED PATCH MANIFEST lib/Net/Netrc.t] Add Tests for Net::Netrc

[not yet sent to p5p; comments welcome] Is this valuable for anyone? I could probably turn something like this into an article for perl.com or the Perl Journal or even use.perl, if anyone could sweet-talk an editor or thinks gonzo testing ought to be promoted. Schwern thinks it's clever, so it

Re: Mock::Socket and the Essentials of Testing libnet

et spot. If we can seperate the net connection from the > protocol, we've got it made. No need for elaborate skip tests and assumptions > about platforms. chromatic did just that. Er, actually, chromatic just fat-fingered Socket::inet_ntoa() and Socket::inet_aton(). (Yeah, they don&#

Re: [PATCH lib/Net/Config.pm, MANIFEST, t/lib/Mock/Socket.pm, lib/Net/Config.t] Add Tests for Net::Config

On Saturday 20 October 2001 11:54, you wrote: > So why is this tested using a mock-up by Net::Config? Sounds like > a job the Socket should be testing (and it is). Oh, no! It's not. Mock::Socket is just a dummy object with the same interface as Socket. It lets the test control the data sent

Re: [PATCH lib/Net/Config.pm, MANIFEST, t/lib/Mock/Socket.pm, lib/Net/Config.t] Add Tests for Net::Config

In article <[EMAIL PROTECTED]>, "Jarkko Hietaniemi" <[EMAIL PROTECTED]> wrote: >> In the process, with some advice from perl-qa, I've added a mock object so >> the test could control the output of Socket::inet_ntoa() and >> Socket::inet_aton(). t/lib/Mock/ seemed like as good a place as any. >

[REPATCH installhtml] Re: installhtml needs a good beating out

In article <[EMAIL PROTECTED]>, "Johan Vromans" <[EMAIL PROTECTED]> wrote: > I'm not sure what you are trying to achieve with this. Really really small incremental changes? > The net efffect is that you get something like > > GetOptions('foo' => \$Options{foo}, 'bar=s' => \$Options{bar}

[proposed PATCH installhtml] Re: installhtml needs a good beating out

In article <20011020014825.J3681@blackrider>, "Michael G Schwern" <[EMAIL PROTECTED]> wrote: > Convert from $opt_* globals to an %Options hash A fun use of map! Is there a test for this beast? A quick 'perl -wc installhtml' verified that it compiles, but refactoring's half complete without

[PATCH lib/Net/Config.pm, MANIFEST, t/lib/Mock/Socket.pm, lib/Net/Config.t] Add Tests for Net::Config

Here's a test suite for Net::Config. In the process of writing this, I've fixed an apparent bug that prevented single values from becoming array references when necessary. I think it's right, but perhaps Graham should weigh in on this. In the process, with some advice from perl-qa, I've added a

Re: Proposed Patch (add tests for Net::Time)

On Thursday 18 October 2001 19:43, Michael G Schwern wrote: > Yes, this is the right way to go! It does rely on knowing that Net::* > use IO::Socket and fiends^Wfriends, but that's ok. Anyone who's maintaining the test really ought to glance over Net::Time at least once. > If it works out, we

Proposed Patch (add tests for Net::Time)

This is *not* being sent to p5p _yet_, because I did something either brilliantly clever or fiendishly stupid to get good coverage. (It's hard to tell the difference.) Relying on reliable networking is pretty unportable, and it's really hard to get useful test information that way. I coded up s

Re: Preliminary test coverage analysis

In article <[EMAIL PROTECTED]>, "schwern" <[EMAIL PROTECTED]> wrote: Going back eight months, this was the state of things. Schwern had just added coverage analysis to Test::Harness: > - A bit less than half of all the core libraries have no coverage at all. > > Some very important things are

Essential Modules Smoke Testing?

Test::Smoke handles bleadperl nicely. Is there a tool to download a set of modules (say, EssentialModules from the Wiki), to run their tests, to collate, and to report the results? Have I just volunteered to write such a beast? It'd be a good idea, at least to get a look at CPAN.pm before someo

Re: [PATCH Test/Simple.pm Test/More.pm] Add skip_rest() Function

On Wednesday 10 October 2001 12:46, Michael G Schwern wrote: > I'm wary of putting this in. I'm afraid that a skip_rest() in a test > wouldn't last long under continued additions to the test. It imposes > a restriction that every test below that point must be effected by it, > and anything you

[PATCH Test::Tutorial] Don't Assume Tests Pass in Test Names

Our fearless pumpking recently weighed in on test names that assume success. What he said made a lot of sense. If a test fails, the message looks all wrong. That may compel some people to fix the tests or the modules, but it may confuse more people. Here's a patch to Test::Tutorial that improve

[PATCH MANIFEST lib/ExtUtils/Mkbootstrap.t] Add Tests for ExtUtils::Mkbootstrap

This passes all tests, within, without t/. Hoping someday to be mentioned in Simon's p5p-summary, -- c --- ~MANIFEST Mon Oct 8 23:56:56 2001 +++ MANIFESTMon Oct 8 23:57:12 2001 @@ -893,6 +893,7 @@ lib/ExtUtils/MANIFEST.SKIP The default MANIFEST.SKIP lib/ExtUtils/Manifest.t

[PATCH lib/Term/Cap.t] Fix Debian Failures on Test 22

In article <[EMAIL PROTECTED]>, "Nicholas Clark" <[EMAIL PROTECTED]> wrote: > 2: Term/Cap.t > # this is ugly, but -f $0 really *ought* to work > > There seems to be some reliance later on in the test on $0 being reliable, but > I've not quite figured out where in Term/Cap.pm this is. The t

[PATCH MANIFEST lib/CPAN/t/Nox.t] Add Tests for CPAN::Nox

All tests pass. Low-hanging fruit. Should I send a copy to Andreas König as well? -- c --- ~MANIFEST Sat Oct 6 21:17:21 2001 +++ MANIFESTSat Oct 6 21:29:34 2001 @@ -852,6 +852,7 @@ lib/CPAN.pmInterface to Comprehensive Perl Archive Network lib/CPAN/FirstTime.pm

[PATCH MANIFEST lib/Term/Cap.t] Add tests for Term::Cap

This adds several tests for Term::Cap. It *should* be portable, as it's pretty cautious about avoiding platform dependencies. Time always tells. Looking at Term::Cap itself, there are some formats mentioned in comments at the start of Tgoto() that aren't implemented. They look pretty obscure.

Re: [PATCH] Test::More isa_ok function

In article <[EMAIL PROTECTED]>, "Dave Rolsky" <[EMAIL PROTECTED]> wrote: > On Tue, 25 Sep 2001, Michael G Schwern wrote: >> A, ok. How about this: >> >> my $yarrow = Bar->new; >> isa_ok($yarrow, "Bar", 'yarrow'); > isa_ok($foo, 'Alzabo::Foo', 'Return value from $bar->foreign_keys

AutoSplit.t Patch (was Re: [PATCH)

In article <[EMAIL PROTECTED]>, "Nicholas Clark" <[EMAIL PROTECTED]> wrote: > I hope this patch works. The one without MANIFEST did. Here's a patch to the patch that ties a filehandle and removes the spawning. I had to tweak one little regex and add a chomp to get things to work. p5p's trimme

Re: Parrot::Test need special support in Test::Simple

In article <20010918185441.J585@blackrider>, "Michael G Schwern" <[EMAIL PROTECTED]> wrote: > It's on my TODO list to decouple the guts of Test::Simple from the external > functions, so it's easier to write Test modules based on it, but it's about > two or three levels down on the list. What mig

Re: A new lease on life for Perl Refactoring

In article <[EMAIL PROTECTED]>, "Andrew M. Langmead" <[EMAIL PROTECTED]> wrote: > So I'd think the best thing to do to make something that can produce answers > to things like "what are the implementors of foo". Ideally, there'd also be a comprehensive test suite to run after the refactoring to

[PATCH Test/Simple.pm Test/More.pm] Add skip_rest() Function

Hi there, I've just added a really simple convenience function that skips the rest of the tests in a suite. It's different from the normal skip() in that it doesn't require nested named blocks. This came about trying to find a better way to fix t/op/lfs.t in bleadperl. (I have a patch for that

[PATCH MANIFEST lib/CGI/t/push.t] New Test for CGI::Push

Just about everything else on the untested list scares me. There are a few modules in ExtUtils::* that need attention, and a handful of Pod::* modules. Someone previously mentioned writing a Pod::Parser test that could be subclassed or extended to cover its children. I might have a look at that