Re: TAP Wiki, TAP for Java
From: Randy J. Ray <[EMAIL PROTECTED]> > And on the topic of Java, if no one else is working on a Java TAP parser, > I'll step up and see what I can craft. I've never heard of one, though I suspect that's because jUnit has been around for so long. If you could have it output TAP, though, that could be our entry into the JAVA world. Not sure how feasible it would be. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
TAP Wiki, TAP for Java
While checking the Wiki page recently pointed to, I noticed that several of the entries under "Producers" are actually parsers. And on the topic of Java, if no one else is working on a Java TAP parser, I'll step up and see what I can craft. Randy -- Randy J. Ray / [EMAIL PROTECTED] Campbell, CA
Send me unusual "make" error strings for CPAN::Reporter
In working on CPAN::Reporter, there's been a snag with test.pl files and
ExtUtils::MakeMaker since the Makefile runs test.pl directly instead of
through Test::Harness. Since output is captured with "tee" to allow user
interaction during tests (if necessary), the exit code is lost. Thus, while
determining t/*.t success or failure can be done by parsing output for
Test::Harness diagnostic messages, determining test.pl exit codes means not
running under "tee" and thus not having any output to report. Thanks to Tim
Bunce for suggesting a way out: parse the output for the error string from
"make".
I was daunted at first by having to reliably do this across any make
program, but after some experimentation with GNU make on linux and both
dmake and nmake on Win32, I think the following regex will work:
qr/$Config{make}.*?:.*?error/i
This will seriously simplify how test.pl files are handled by
CPAN::Reporter.
So -- to make this more robust, I'm looking for any make error string that
breaks this regex. Any failing Makefile should do. E.g.:
all:
perl -e "die"
If you have access to other platforms, please see what your "make" program
returns on failure and let me know.
Thanks very much.
Regards,
David Golden
Re: Don't 'rm -fr /' when testing
* Ovid <[EMAIL PROTECTED]> [2006-09-26T09:19:46]
> > It would be nice if I could just write 'use My::Test::More' in my
> > test scripts and have that provide what I need
>
> Side note: yes, it's trivial for me to write an extra module which provide
> an environment variable or something similar for this, but I like the idea of
> hooking this onto Test::More since we rely on this module for *every* test
> script and thus can't forget to include it.
I thought this could be done in a nice simple way by exporting curried methods,
but then I remembered that using methods would chomp prototypes. The attached
code has a few jagged edges (doesn't use exported_to, etc), but I gave up on
polishing them when I realized the prototype issue; maybe B::something can fix
that.
This would have made it possible to "subclass" Test::More, but maintain the
interface, so you could write:
package Test::Most;
use base qw(Moog);
sub ok {
my ($class, $bool, $comment) = @_;
for (1..10) { $class->SUPER($bool, $comment); }
}
This was probably more a way to waste a couple minutes than a good path
forward, but YMMV.
--
rjbs
package Moog;
use strict;
use warnings;
use Test::More ();
use Sub::Exporter ();
use Sub::Exporter::Util ();
use base qw(Test::Builder::Module);
BEGIN {
no strict 'refs';
for my $sub (@Test::More::EXPORT) {
*{$sub} = sub { shift; &{"Test::More::$sub"}(@_); };
}
Sub::Exporter::setup_exporter({
as => 'import_code',
exports=> [
map { $_ => Sub::Exporter::Util::curry_class($_) } @Test::More::EXPORT
],
groups => { default => [':all'] },
});
}
sub import_extra {
my ($class, $things) = @_;
my %ok = map { $_ => 1 } @Test::More::EXPORT;
$class->import_code(
{ into_level => 2, },
grep { $ok{$_} } @$things
);
}
1;
Re: Don't 'rm -fr /' when testing
Ovid wrote:
> From: Christopher H. Laco <[EMAIL PROTECTED]>
>
>> I'm thinking about doing the same thing. Before Chris Dolan wrote a
>> Testing::RequireTestLabels policy for me (thanks!), I was going to
>> subclass Test::More and expose the usual methods and tack on my argument
>> checking.
>
> Just threw this together and it seems to do the trick.
>
> package My::Test::More;
>
> use Test::Builder::Module;
> @ISA= qw(Test::Builder::Module);
> use Test::More;
>
> @EXPORT = @Test::More::EXPORT;
>
> # add whatever you need here:
> $ENV{WE_BE_TESTING} = 1;
>
> 1;
>
> And in your regular code, use it like normal:
>
> use My::Test::More tests => 23;
>
> Cheers,
> Ovid
>
Time to show my ignorance. Why use Builder::Module directly instead of:
@ISA= qw(Test::More);
@EXPORT = @Test::More::EXPORT;
-=Chris
signature.asc
Description: OpenPGP digital signature
Re: Don't 'rm -fr /' when testing
On 26 Sep 2006, at 14:59, Ovid wrote: [snip] (You know, you could probably use that to do interesting things like caching the last time a given developer ran tests. Hmm, why anyone want to do that?) [snip] So you can do interesting things like run tests in "most recently failed" order? (or was that one of those hypothetical questions :) Adrian
Re: Don't 'rm -fr /' when testing
- Original Message From: Andy Lester <[EMAIL PROTECTED]> > That's one of the nice things about prove, is that you can say prove - > v testname.t and still get HARNESS_ACTIVE. Agreed, but when someone forgets and runs the test program directly with 'perl', I can't risk more email being sent out. It's easy to forget and mistype. Plus, in vim, I have ',r' (r)un the current file with Perl and ',t' (t)est the current file with prove. I've mistyped more than once :) Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Don't 'rm -fr /' when testing
On Sep 26, 2006, at 8:13 AM, Ovid wrote: but I think it would be helpful to have something a bit more reliable (that variable's not set if I just run the tests with 'perl testname.t'). That's one of the nice things about prove, is that you can say prove - v testname.t and still get HARNESS_ACTIVE. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Don't 'rm -fr /' when testing
From: Christopher H. Laco <[EMAIL PROTECTED]>
> I'm thinking about doing the same thing. Before Chris Dolan wrote a
> Testing::RequireTestLabels policy for me (thanks!), I was going to
> subclass Test::More and expose the usual methods and tack on my argument
> checking.
Just threw this together and it seems to do the trick.
package My::Test::More;
use Test::Builder::Module;
@ISA= qw(Test::Builder::Module);
use Test::More;
@EXPORT = @Test::More::EXPORT;
# add whatever you need here:
$ENV{WE_BE_TESTING} = 1;
1;
And in your regular code, use it like normal:
use My::Test::More tests => 23;
Cheers,
Ovid
--
Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Don't 'rm -fr /' when testing
Ovid wrote: [snip] > It would be nice if I could just write 'use My::Test::More' in my test > scripts and have that provide what I need, but I'm not sure if trying to > re-export all of the test functions from Test::More (kind of like subclassing > which isn't a class) is a bright idea, but it's the cleanest I can think of. > Am I missing something really obvious here? > > Cheers, > Ovid > I'm thinking about doing the same thing. Before Chris Dolan wrote a Testing::RequireTestLabels policy for me (thanks!), I was going to subclass Test::More and expose the usual methods and tack on my argument checking. I still may do it just to merge my Handel::Test (SQLite schema init/populate) and my use of Test::More into one interface. -=Chris signature.asc Description: OpenPGP digital signature
Re: Don't 'rm -fr /' when testing
- Original Message From: Ovid <[EMAIL PROTECTED]> > It would be nice if I could just write 'use My::Test::More' in my > test scripts and have that provide what I need Side note: yes, it's trivial for me to write an extra module which provide an environment variable or something similar for this, but I like the idea of hooking this onto Test::More since we rely on this module for *every* test script and thus can't forget to include it. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Don't 'rm -fr /' when testing
From: Yuval Kogman <[EMAIL PROTECTED]>
> What about
>
>$some_object->send_email(@args);
>
> and having your test code:
>
>a. replace the object (probably a singleton or an obj in a
>global) with a mock object that doesn't actually send email
>
>b. also test that send_email is being called when appropriate
While that's the general strategy, this is working with a lot of legacy code
which is, to be kind, not written to today's standards. Fortunately, most of
this code already checks an $ENV{DEVEL} variable. Merely by ensuring that this
variable is set to a true value, I can protect against much of the worst.
There's simply no way I can go through all of the code right now and possibly
hope to catch all cases where things might blow up. The 'My::Test::Class'
solution seems to work now.
(You know, you could probably use that to do interesting things like caching
the last time a given developer ran tests. Hmm, why anyone want to do that?)
Just to give you an idea of the problem I'm faced with:
http://use.perl.org/~Ovid/journal/31057
Cheers,
Ovid
--
Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Don't 'rm -fr /' when testing
On Tue, Sep 26, 2006 at 06:13:11 -0700, Ovid wrote:
> unless ( defined &Test::More::ok ) { send_email(@args) }
What about
$some_object->send_email(@args);
and having your test code:
a. replace the object (probably a singleton or an obj in a
global) with a mock object that doesn't actually send email
b. also test that send_email is being called when appropriate
--
Yuval Kogman <[EMAIL PROTECTED]>
http://nothingmuch.woobling.org 0xEBD27418
pgpRLfNaMNA86.pgp
Description: PGP signature
Don't 'rm -fr /' when testing
I'm really not sure of the best way to handle this, so I thought I'd toss this
out to some of you folks.
I recently found out that one of my test programs accidentally sent a bunch of
error email to our support staff. There's often an environment variable named
'HARNESS_ACTIVE' if tests are being run, but I think it would be helpful to
have something a bit more reliable (that variable's not set if I just run the
tests with 'perl testname.t'). For the time being, I have the following check
in my code:
unless ( defined &Test::More::ok ) { send_email(@args) }
However, I don't feel entirely comfortable with that (and %INC check would be
just as bad). If some errant code were to load Test::More for some silly
reason, I'm not going to send error email.
It would be nice if I could just write 'use My::Test::More' in my test scripts
and have that provide what I need, but I'm not sure if trying to re-export all
of the test functions from Test::More (kind of like subclassing which isn't a
class) is a bright idea, but it's the cleanest I can think of. Am I missing
something really obvious here?
Cheers,
Ovid
--
Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: OT: cross-platform path handling
I've uploaded a version that works as advertised and runs its test suite successfully on MSWin32, Cygwin, OpenBSD, and Linux. If you happen to have a more obscure OS around, I'd love to hear whether or not it works. (Of course, any other comments are also welcome!) >Directory-Scratch-0.09.tar.gz > > has entered CPAN as > > file: $CPAN/authors/id/J/JR/JROCKWAY/Directory-Scratch-0.09.tar.gz > size: 36142 bytes > md5: 7ae1eb53cbe07a6dcb2b5cba9b9c45ac Regards, Jonathan Rockway Jonathan Rockway wrote: > BTW, my Directory::Scratch module is meant to solve this problem. At > the top of your program you: > > use Directory::Scratch "YourOS" > > and all path names passed to the module are interpreted as though > they're from YourOS, even when running on some other OS. This means > that you can use UNIX path names in your tests, and they'll work > everywhere Path::Class does. (Of course, you can use Win32/VMS/MacOS > paths, also; but UNIX is the default.) > > The version of D::S on CPAN right now is kind of embarrassing (got a few > patches and applied them even though I felt uneasy about them), but I'll > have a fixed version up tonight. > > So don't try the module yet -- I'll send another note to the list when > I'm happy with it :) > > Regards, > Jonathan Rockway > > (Disclaimer: nothing is broken in the current version, but it does > assume that you're using your native OS's paths. So if you don't care > about cross-platform usability, go ahead and use it now. In addition, > the tests are kind of "icky", as are some of the features. YMMV. :) > > A. Pagaltzis wrote: > >> * David Golden <[EMAIL PROTECTED]> [2006-09-18 12:30]: >> >>> Many of the test failures can be attributed to: >>> >>> * non-portable path expectations >>> >> Btw, is there a chance of Path::Class becoming core? >> >> It is *so* *much* better than File::Find, File::Basename, >> File::Spec and the rest of the entourage it’s not even funny. And >> it’s also sane, as opposed to IO::All. >> >> Regards, >> signature.asc Description: OpenPGP digital signature
