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
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
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
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
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
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
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
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
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()
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
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
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
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
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';
+}
+}
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
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,
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
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
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,
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
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
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 /
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
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
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
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
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
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
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
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
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
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
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
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.
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 ); #
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
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 not
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
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't really require nameservers. No, the
real ones don't
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.
I'm not
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
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
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
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 +usage() if defined
$Options{help};
+$Options{help
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 24
Yeah,
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
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
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
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()
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
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
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
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 might this
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';
+}
+}
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
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
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
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( $^H 0x0020, 1, '... and again' );
These tests are wrong. $^H
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
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
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 @@
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
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
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
://wgz.org/chromatic/perl/Test-MockObject.tar.gz
Suggestions, comments, and patches welcome.
-- c
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
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, patching the patch
to say
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
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
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,
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
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
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 /
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
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
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 good
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
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
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
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 { my $obj =
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
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
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
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've
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.
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 chromatic
On Wednesday, July 16, 2003, at 07:28 AM, Potozniak, Andrew wrote:
I'm getting into testing a lot more lately and I realize that
Test::More
doesn't do what I would like it to do and thus I'm creating my own test
class.
If your new module uses Test::Builder, you can use it and Test::More
On Thursday, July 24, 2003, at 09:46 AM, Potozniak, Andrew wrote:
Correct me if I'm wrong but calling $self-SUPER::somesub calls a sub
in the
functional context which will not pass the calling class along with
it.
Okay, you're wrong. :)
'SUPER::' is just a hint to the method dispatcher to
On Thu, 2003-10-16 at 10:46, Ovid wrote:
I was browsing through the Perl core tests and I saw that some tests in the t/uni/
directory used
Test::More, but most other tests would explicitly 'print ok 1\n'.
Is this to reduce the dependancy of the core tests on external modules (and if so,
On Mon, 2004-02-02 at 15:46, Adrian Howard wrote:
However, I was wondering if anybody else ever wanted to do this sort of
thing and, if so, would a more generic API to the test name be useful -
e.g. localising something like $Test::Builder::Test_name?
If so, I can probably be persuaded to
On Tue, 2004-02-03 at 12:46, Tels wrote:
I still think a big warning should be added to Test::More beeing _not_ a
drop-in replacement to Test.
I can only remember calling it a drop-in replacement for Test::Simple.
-- c
On Tue, 2004-05-11 at 15:19, stevan little wrote:
If 5.6.1 is the official minimum, then maybe this brings back up the -w
vs. warnings issue? Since Ovid pointed out that 5.6 was the minimum for
the warnings pragma, and 5.6.1 is your official minimum, it seems
maybe the choice is back on
On Fri, 2004-05-21 at 09:02, Geoffrey Young wrote:
another thing that is keeping me from 100% right now is the
classic
my $class = ref $self || $self;
where the only way to satisfy the conditional is to call My::Foo::bar()
using functional syntax instead of a method syntax.
Wouldn't
On Tue, 2004-05-25 at 06:58, Francisco Olarte Sanz wrote:
I've been looking at the documentation for the test modules (Test::More,
Test::Simple, Test::Builder ), and I've found nothing regarding the return
value of the ok(), is(), etc... functions/methods. Browsing through the
source
On Thu, 2004-06-24 at 11:59, Andrew Pimlott wrote:
Every time I hear about xUnit, I figure there must be something other
than setup and teardown in its favor. If that's all there is, I'm not
sold.
It's the best option for languages that enforce a nominally pure OO
style.
(During the tech
On Wed, 2004-07-07 at 17:07, Andrew Pimlott wrote:
Interesting. Aside: I'm glad to have it, as the whole plan business
was one of the turn-offs of the standard Test modules in the past. Is
the tedium of counting tests really worth it for anyone?
Tedium is the mother of invention.
Add
On Mon, 2004-08-09 at 13:18, Geoffrey Young wrote:
hrmph. now that you mention it, yeah, it does. and there's already
Test::MockObject (which I've heard about but obviously haven't actually used
yet :)
The author is very handsome, too.
yeah, that was the real goal. perhaps a subclass of
On Fri, 2004-08-20 at 11:24, Geoffrey Young wrote:
Test::MockObject is clearly object/instance based.
Test::MockObject::Extends is documented to mock either an object or the
class as a whole. if that's not the case that is fine (I guess ;), but then
I'm very confused what value passing a
On Fri, 2004-08-27 at 01:09, Andrew Pimlott wrote:
I would still prefer that Test::Builder not use threads if I don't ask
for it.
if( $] = 5.008 $Config{useithreads} ) {
require threads;
require threads::shared;
threads::shared-import;
}
If you don't have an
On Fri, 2004-08-27 at 11:03, Andrew Pimlott wrote:
And most tests, even of threaded code, will call T::B from a single thread
anyhow.
How do you know what tests people will write? How do you know where
people will run those tests?
There are two ways to do the compromise:
1. Go thread
1 - 100 of 442 matches
Mail list logo
