Re: TAPx::Harness support for EUMM
Andy Armstrong wrote: On 27 Jan 2007, at 19:10, Andy Armstrong wrote: I've just committed a patch against ExtUtils::MakeMaker 6.31 that makes test_harness use TAPx::Harness instead of Test::Harness if the env variable PERL_EUMM_USE_TAPX is set to a true value and TAPx::Harness is installed. I should clarify: I haven't patched EUMM; I've made a patch that can be applied against EUMM and made it available in our svn. Umm, yeah. I was wondering about that.
Re: TAPx::Harness support for EUMM
Andy Armstrong wrote:
I've just committed a patch against ExtUtils::MakeMaker 6.31 that makes
test_harness use TAPx::Harness instead of Test::Harness if the env
variable PERL_EUMM_USE_TAPX is set to a true value and TAPx::Harness is
installed.
EUMM Patch:
http://svn.hexten.net/tapx/patches/ExtUtils-MakeMaker-6.31.patch
I couldn't accept this patch to MM. This would lead to MM's environment being
littered with PERL_EUMM_USE_FLAVOR_OF_THE_WEEK. And if TAPx::Harness is going
to be the guts for Test::Harness anyway there isn't much point.
Need something a bit more generic. Perhaps make it easier to override the
behavior of test_harness()?
Also fall through logic makes my eyes bleed. Rather than this...
if ($ENV{PERL_EUMM_USE_TAPX}) {
eval require TAPx::Harness;
unless ($@) {
...TAPx code...
return;
}
}
# Fallback: use Test::Harness
Do this.
if( $ENV{PERL_EUMM_USE_TAPX} eval require TAPx::Harness ) {
...TAPx code...
}
else {
...Test::Harness code...
}
Or if the condition for checking to use TAPx::Harness were more complex you can
figure it out beforehand and roll the decision up into $use_tapx.
Re: TAPx::Harness support for EUMM
On 29 Jan 2007, at 12:41, Michael G Schwern wrote: Umm, yeah. I was wondering about that. Sorry for the confusion. The patch serves two purposes: 1) It makes it possible for people to try TAPx::Harness and easily disable it if they run into problems 2) It's part of me working out the role of the TAPx::Harness::Compatible code. I'm trying to identify cases where extant code can easily be made compatible with the new TAPx::Harness interface as part of understanding how the compatibility layer is likely to be used. -- Andy Armstrong, hexten.net
Re: TAPx::Harness support for EUMM
On 29 Jan 2007, at 12:57, Michael G Schwern wrote:
EUMM Patch: http://svn.hexten.net/tapx/patches/ExtUtils-
MakeMaker-6.31.patch
I couldn't accept this patch to MM. This would lead to MM's
environment being littered with PERL_EUMM_USE_FLAVOR_OF_THE_WEEK.
And if TAPx::Harness is going to be the guts for Test::Harness
anyway there isn't much point.
Indeed. I should have been more explicit about my intentions here.
It's offered only as a simple way of injecting TAPx::Harness just now
so that people can play with it in a fairly risk free way.
Actually produced the patch so that *I* can play with TAPx::Harness -
and thought it might be useful for others in the same way.
Need something a bit more generic. Perhaps make it easier to
override the behavior of test_harness()?
Sure - I'm open to suggestions. Do you mean something like this?:
$ export PERL_EUMM_HARNESS_CLASS=TAPx::Harness::Compatible
$ make test
Also fall through logic makes my eyes bleed. Rather than this...
if ($ENV{PERL_EUMM_USE_TAPX}) {
eval require TAPx::Harness;
unless ($@) {
...TAPx code...
return;
}
}
# Fallback: use Test::Harness
Do this.
if( $ENV{PERL_EUMM_USE_TAPX} eval require TAPx::Harness ) {
...TAPx code...
}
else {
...Test::Harness code...
}
Or if the condition for checking to use TAPx::Harness were more
complex you can figure it out beforehand and roll the decision up
into $use_tapx.
Yes indeed. But as you say it'd be nicer still to be able to plug in
any alternative harness.
--
Andy Armstrong, hexten.net
Re: TAPx::Harness support for EUMM
--- Andy Armstrong [EMAIL PROTECTED] wrote: Or if the condition for checking to use TAPx::Harness were more complex you can figure it out beforehand and roll the decision up into $use_tapx. Yes indeed. But as you say it'd be nicer still to be able to plug in any alternative harness. Agreed. Particularly since a large impetus of this project is to allow folks to write custom harnesses for their needs. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: TAPx::Harness support for EUMM
Andy Armstrong wrote:
Sure - I'm open to suggestions. Do you mean something like this?:
$ export PERL_EUMM_HARNESS_CLASS=TAPx::Harness::Compatible
$ make test
That's one way, though I'd rather it be a Makefile.PL argument. [1]
The way I was thinking was to make it easier for users to write
MY::test_harness() so they can plug in any testing system, not just
Test::Harness compatible ones. This would mostly involve separating the
scaffolding code (expanding and sorting the arguments, fixing up @INC) from the
Test::Harness specific stuff. Something like:
sub test_harness {
require Test::Harness;
require File::Spec;
my $verbose = shift;
# Because Windows doesn't do this for us and listing all the *.t files
# out on the command line can blow over its exec limit.
require ExtUtils::Command;
my @files = sort { lc $a cmp lc $b }
ExtUtils::Command::expand_wildcards(@ARGV);
local @INC = @INC;
unshift @INC, map { File::Spec-rel2abs($_) } @_;
run_tests(files = [EMAIL PROTECTED], verbose = $verbose);
}
sub run_tests {
my %args = @_;
$Test::Harness::verbose = $args{verbose};
return Test::Harness::runtests(@{$args{files}});
}
Then all you have to override is run_tests().
[1] Or, for the really adventurous... implement a makemakerrc.
