On Mon, 10 Sep 2001, Doug MacEachern wrote:
> On Mon, 10 Sep 2001, Stas Bekman wrote:
>
> > + my $configure_sub = *{$module."::APACHE_TEST_CONFIGURE"}{CODE};
>
> would prefer using $module->can('APACHE_TEST_CONFIGURE') here.
Yup, I was thinking about that, but figured it'd be more expensive. I know
we don't care much about speed in tests :) so can() should be fine.
> > TestModules::cgiupload barks at Apache::OK undefined, patched with:
> >
> > +use Apache::Const -compile => 'OK';
>
> yeah, the common ones normally compiled in modperl_startup.pl
But at this point modperl_extra.pl (where it actually happens) is not
loaded yet :)
What do you think is the right position for writing tests? Should these be
standalone or rely on the fact that somebody else maybe has compiled
constants for them. I'm fine with adding these compile calls as I find
problems, so if it makes tests cleaner I'm willing to clean up.
> > t/response/TestAPI/aplog.pm barks at Apache::LOG_MARK undefined,
> >
> > I don't know how to make it available at require() time. We explicitly
> > don't import the APLOG_MARK from Apache headers, but then I cannot find
> > where it's done. I have found this:
> >
> > ./xs/maps/modperl_functions.map:DEFINE_LOG_MARK | MPXS_Apache_LOG_MARK |
>...
> >
> > and these are autogenerated:
> > ./xs/Apache/Log/Apache__Log.h:static XS(MPXS_Apache_LOG_MARK)
> > ./WrapXS/Apache/Log/Log.xs: cv = newXS("Apache::LOG_MARK", MPXS_Apache_LOG_MARK,
>__FILE__);
> >
> > where is the code that does return (__FILE__, __LINE__) ?
>
> Apache__Log.h:
> EXTEND(SP, 2);
> PUSHs_mortal_pv(CopFILE(cop));
> PUSHs_mortal_iv(CopLINE(cop));
doh! I didn't expect code in .h :) sure should have checked that. thanks!
> you can do something like:
> unless (defined &Apache::LOG_MARK) {
> *Apache::LOG_MARK = sub { #get file/line using caller() }
> }
But this can be a problem. Since the file will be in %INC already, it'll
keep on using bogus *Apache::LOG_MARK . Unless you actually suggest to
implement it in what you've placed as a comment.
> > ---------
> > t/filter/TestFilter/input_body.pm seem not to have attributes inherited
> > via require()
> >
> > Invalid CODE attribute: FilterRequestHandler at
> > /home/stas/apache.org/registry/t/filter/TestFilter/input_body.pm line 15
>
> and similar:
> unless (defined &Apache::Filter::MODIFY_CODE_ATTRIBUTES) {
> ...
> }
Ditto, the test may not work later, unless we delete $INC{...}
But can you please explain why require() doesn't work here? Is it because
something else happens behind the walls when the server is up?
> > also, does ModPerl::Const::compile accepts only a single arg in the
> > string on purpose? e.g. it's not possible to say: -compile 'foo bar';
>
> why should it be possible? Exporter.pm doesn't support that. just use
> the standard calling convention:
> -compile => qw(foo bar);
That's correct. my wrong.
> i'm starting to think supporting APACHE_TEST_CONFIGURE is going to be
> more trouble than its worth. it is also going to slow things down
> having to require/compile every .pm on the client side before running
> tests. the majority of .pm tests will not have an
> APACHE_TEST_CONFIGURE. i'd rather see, if possible, the .t files that
> need setup of directories/files use your new Apache::TestUtil
> functions instead. what do you think?
Yup, I was exactly thinking about that. It'll be so much simpler to use
Apache::TestUtil. I don't think it makes things slower.
So should I just give up the idea of APACHE_TEST_CONFIGURE and move on
with Apache::TestUtil like vhost_alias does?
Let's just think for a sec, whether we may have some other reason for
having something like APACHE_TEST_CONFIGURE? Was the creation of the files
on the fly the only reason for wanting this?
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
