httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: Apache::TestMB
Date Tue, 22 Jun 2004 17:33:13 GMT
David Wheeler wrote:
> On Jun 21, 2004, at 6:12 PM, David Wheeler wrote:
>> Here's a new subclass for Module::Build, Apache::TestMB, which allows 
>> modules that use Module::Build to run tests using Apache::Test.
> Let me make a few comments on my "XXX" comments in the source code, and 
> aske a couple of questions:
> * In ACTION_test_clean() and ACTION_run_tests(), I'd love to be able to 
> dump the dependence on t/TEST. My thought was to make calling 
> generate_script() optional. It would only be called by module developers 
> who had special needs, and had created t/TEST.PL to handle them. If this 
> method was never called (and therefore apache_test_script had no value), 
> then ACTION_test_clean() and ACTION_run_tests() could carry out their 
> actions directly.

> This is Perl, after all, so theoretically, Build doing the work is the 
> same as t/TEST doing the work. I tried to implement this, but it looked 
> like there were too many dependencies on the presence of t/TEST in 
> Apache::TestRun::run. It also takes a whole slew of options. These 
> issues would have to be addressed before we could make t/TEST optional. 
> Ideally, ACTION_test() would just look like this:
> sub ACTION_run_tests {
>     my $self = shift;
>     $self->depends_on('code');
>     $self->depends_on('test_clean');
>     my @files = $ENV{TEST_FILES} ? ($ENV{TEST_FILES}) : ();
>     if (my $script = $self->apache_test_script) {
>         # Execute the test script.
>         return $self->do_system($self->perl, $self->_bliblib,
>                                 $self->localize_file_path($script),
>                                 '-bugreport',
>                                 ('-verbose=' . ($self->verbose || 0)),
>                                 @files);
>     }
>     # Just run things directly.
>     $self->depends_on('start_httpd');
>     $self->SUPER::ACTION_test(@_);
>     $self->depends_on('kill_httpd');
>     $self->depends_on('test_clean');
> }
> Stas, is it possible to implement the necessary methods to do what 
> t/TEST normally does from within Module::Build?

Absolutely. It's really just:


where MyTest is a subclass of Apache::TestRunPerl

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. May be you should use a wrapper around t/TEST which works 
just the same.

> * 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?

> * This isn't commented in the code I sent you, but I'll note it: I 
> didn't implement "cmodules" or "cmodules_clean" actions. They appear 
> simple, but they seem to depend on `make` rather than Module::Build. 
> Stas, are these just that simple? Should I expect that there'd be a 
> Makefile in the cmodules directory? Or might it be Module::Build-based? 
> I guess the real question is, where does that Makefile come from?

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.

I've skimmed the source, it looks good David, but please use indentation of 4 

Also how the following code is supposed to work?

     my $infile = '$script.PL';
     if (-f $infile) {

Also you can use shortcuts from Apache::TestTrace to do logging.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message