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
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
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.
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
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
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
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
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&#
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.
>
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 a
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}
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
[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
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
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
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.
>
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
-
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
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
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.
>
>
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
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
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
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 @MM::
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
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
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 t
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]>, "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
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
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 informati
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
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
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
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 @@
$args->{
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
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
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
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
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
@@
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
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
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
nd at:
http://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 M
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
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
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
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,
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
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
> tou
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
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,
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 wa
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
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
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
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?
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
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
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
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
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
) $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
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'
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
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
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
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
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
together
On Friday, July 18, 2003, at 10:36 AM, Tony Bowden wrote:
What's the current approach to turning perlbugs into tests?
In general, the person who fixes the bug writes a regression test for
the bug. The pumpkings and other porters are really good about making
sure patches have tests.
Should they
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 m
On Friday, August 1, 2003, at 05:03 PM, Michael G Schwern wrote:
Ooooh! I just had a great idea. Use "TEST { ... }" instead of "TEST:
{ ... }"
in Test::AtRuntime. If the user has Filter::Simple, use that to strip
out
the TEST blocks. Otherwise, its a function call to TEST() passing in
a cod
On Tuesday, September 9, 2003, at 11:23 AM, Tels wrote:
From my point of view is_deeply() is an extended ok(), which also walks
arrays, hashes and other (possible nested) structures, and then
compares
_each_ element.
This is how I've always seen it, assuming Tels meant is() instead of
ok() above
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
On Mon, 2003-11-17 at 06:54, Potozniak, Andrew wrote:
> What's stopping you from creating this global var
> and passing it in to the function whenever it is called?
Good taste. If it's going to be more convenient than Test::More's
like(), go all the way and make it more convenient.
> Or you cou
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 persuade
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 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.
Woul
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
> sourc
On Tue, 2004-06-08 at 20:18, Andrew Savige wrote:
> I am currently using Test::More for my Perl white-box unit tests.
> I also need to write some C/C++ white-box unit tests and would like
> to use something similar in spirit to Test::More.
What if you used Inline::C *and* Test::More? If they're
Hi all,
Nat's latest journal entry (http://use.perl.org/~gnat/journal/19351)
suggests coming up with some test-first Kata in Perl. Kata are small
exercises that don't really matter except as learning experiences
(http://pragprog.com/pragdave/Practices/CodeKata.rdoc).
Is anyone else interested in
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 tec
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 no
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 o
On Fri, 2004-08-20 at 11:03, Geoffrey Young wrote:
> hmph, I'm actually having a difficult time getting ::Extends to do what I
> would think it would do. consider
>
> use Test::MockObject::Extends;
> my $mock = Test::MockObject::Extends->new('IO::File');
> $mock->mock('open', sub { print "
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
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 threa
1 - 100 of 518 matches
Mail list logo
