Re: Literal Values

2002-11-12 Thread chromatic
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.12343 ); #

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

2002-11-11 Thread chromatic
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 in

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

2002-11-11 Thread chromatic
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::Harness.

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

2002-10-24 Thread chromatic
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

2002-10-14 Thread chromatic
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 and #2 are

Re: Help spreading Test

2002-08-28 Thread chromatic
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 seems

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

2002-08-18 Thread chromatic
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

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

2002-07-31 Thread chromatic
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? Let's

Re: [perl #15479] perl 5.8.0 segfault

2002-07-31 Thread chromatic
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 for

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

2002-07-27 Thread chromatic
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

Re: Help spreading Test

2002-07-27 Thread chromatic
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

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

2002-07-05 Thread chromatic
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

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

2002-06-30 Thread chromatic
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

2002-06-27 Thread chromatic
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

2002-06-08 Thread chromatic
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 touched,

Re: Pondering Test::Depend

2002-06-08 Thread chromatic
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 given

Re: Pondering Test::Depend

2002-06-08 Thread chromatic
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, and

Re: Test::MockObject 0.03

2002-04-29 Thread chromatic
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 Mock

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

2002-01-27 Thread chromatic
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

Re: is() with arbitrary comparisions

2001-12-19 Thread chromatic
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() $that

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

2001-12-19 Thread chromatic
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,

Re: Tentative Term::ReadLine patch/test

2001-12-08 Thread chromatic
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'; +} +}

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

2001-11-25 Thread chromatic
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

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

2001-11-25 Thread chromatic
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

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

2001-11-25 Thread chromatic
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... +# test

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

2001-11-25 Thread chromatic
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_script()

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

2001-11-24 Thread chromatic
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. is( undef, undef ); # ok is( 0

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

2001-10-20 Thread chromatic
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

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

2001-10-11 Thread chromatic
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 lib/Term/Cap.t] Fix Debian Failures on Test 22

2001-10-08 Thread chromatic
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 test

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

2001-10-08 Thread chromatic
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

Re: [PATCH] Test::More isa_ok function

2001-09-25 Thread chromatic
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 should be

AutoSplit.t Patch (was Re: [PATCH)

2001-09-24 Thread chromatic
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 trimmed from

Re: A new lease on life for Perl Refactoring

2001-09-17 Thread chromatic
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 see what

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

2001-09-15 Thread chromatic
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