On Jun 22, 2004, at 10:33 AM, Stas Bekman wrote:
Absolutely. It's really just:
MyTest->new->run(@ARGV);
where MyTest is a subclass of Apache::TestRunPerl
I tried that, but it didn't work. I'm not sure why. The first problem was this code:
$0 = File::Spec->rel2abs($0);
if (-e $0) {
my $top = dirname dirname $0;
chdir $top if $top and -d $top;
}Which moved things out of the module root, since Build.PL isn't in t/. I got 'round that by doing C<local $0 = ''>, but then nothing else happened. Odd.
Though you will need to figure out how to pass the options, which is already not trivial at all, since there are quite a few ways to feed them in at different phases.
Yes, that's the other thing I wanted to avoid.
May be you should use a wrapper around t/TEST which works just the same.
That's the way it works now.
* I wasn't sure how the TEST_FILES environment variable was supposed to work. So I'm just passing it to the call to t/TEST if it exists. Stas, is this the correct thing to do?
I think yes, but why not keep it an env var?
It is an environment variable. If, however, you mean that t/TEST spots the environment variable and does the right thing, then cool, I'll simply take out out of TestMB.
I believe it's autogenerated, I didn't write that code, so you can look just as well :) You can use libapreq-2's source from CPAN to see how c-modules work.
Pass. I don't really do C. I put in some stubs for it, though.
I've skimmed the source, it looks good David, but please use indentation of 4 everywhere.
I did; only lines that continue from a previous line use two spaces. If you want four there (confusing, IMO), I can change it.
Also how the following code is supposed to work?
my $infile = '$script.PL'; if (-f $infile) {
It will use t/TEST.PL to generate t/TEST if t/TEST.PL exists. Otherwise, it generates t/TEST like TestConfig::generate_script(). does.
Also you can use shortcuts from Apache::TestTrace to do logging.
Um, I have no idea what you're talking about here. Sorry.
Regards,
David
