Re: Perl Testing

2003-07-09 Thread Stas Bekman
David Wheeler wrote:
On Thursday, June 19, 2003, at 09:13  AM, Geoffrey Young wrote:
I think he means by adding your own ServerRoot directive to 
extra.last.conf.in.  however, I see what you are saying and that won't 
likely resolve your issue.

Yes, and I can't know what it is ahead of time. I don't expect that this 
would work:

ServerRoot @ServerRoot@/..
either at run-time:
t/TEST -serverroot /my/server/root
or in your t/TEST script:
$Apache::TestConfig::Argv{serverroot} = /my/server/root;
or in your Makefile.PL:
push @ARGV, qw(-serverroot /my/server/root);
Apache::TestMM::filter_args();
Apache::TestMM::generate_script(t/TEST);
I haven't tested that, but it should work just like all other overrides, no? 
t/TEST --help shows all the available options

is there some reason that you want to backtrack to t/ in your test 
scripts?  for the most part, I put things I need under t/, including 
libraries and other cruft, so that everything is relative to the 
default ServerRoot setting.

I _do_ want t to be the ServerRoot. But I _don't_ want t/ to be cwd for 
all of the tests that run (t/*.t). cwd during `make test` should be the 
package root directory. For example, I have a test script, t/01basic.t, 
that opens the error log to look for error messages from the Apache test 
server. Under Apache::test (and any other CPAN test suite that runs via 
Perl's usual `make test`), I would have to open it like this:

  open ERR, 't/logs/error_log' or die Can't do it: $!\n;
However, under the default `make test` with Apache::Test, it changes the 
cwd to t. This is not where CPAN modules should be tested from. It 
forces me to open the error log like this, instead:

  open ERR, 'logs/error_log' or die Can't do it: $!\n;
That's what I think should be changed.
Hope I've explained it better this time! :-)
don't rely on cwd, use the full path:
  my $vars = Apache::Test::vars();
  my $path = catfile $vars-{serverroot}, qw(logs error_log);
Does that solve your problem?
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Re: Perl Testing

2003-06-20 Thread Geoffrey Young

It does seem inconsistent to have the CWD be $root for the test scripts, 
but $root/t for the server process.  One more quirk to remember.
but isn't that exactly the opposite of what David's issue is?
 It forces me to open the error log like this, instead:

   open ERR, 'logs/error_log' or die Can't do it: $!\n;
so, as things stand now, cwd for both *.t scripts and the server process is 
ServerRoot (aka, t/), which makes perfect sense to me :)

I guess the quirk is that for Apache-Test *.t scripts the cdw is different 
than it is for standard CPAN distributions.

or maybe I just haven't gotten enough sleep lately...
--Geoff



Re: Perl Testing

2003-06-20 Thread David Wheeler
On Thursday, June 19, 2003, at 08:13  PM, Geoffrey Young wrote:
It does seem inconsistent to have the CWD be $root for the test 
scripts, but $root/t for the server process.  One more quirk to 
remember.
Well, maybe, but I've always kinda thought of t/ as the ServerRoot, 
anyway. I like that I can set the document root with variables in 
t/conf/extra/conf.in, though. That's a big bonus!

but isn't that exactly the opposite of what David's issue is?
No, just an inconsistency to note. Not so inconsistent to me, though.
so, as things stand now, cwd for both *.t scripts and the server 
process is ServerRoot (aka, t/), which makes perfect sense to me :)
Yeah, that's wrong according to perl module testing standards. If they 
need to be consistent, then the module distribution root should be 
ServerRoot, too. Perhaps @ServerRoot@/t could be the default 
DocumentRoot?

I guess the quirk is that for Apache-Test *.t scripts the cdw is 
different than it is for standard CPAN distributions.
That's correct, and exactly the issue.
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED]  ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
   Jabber: [EMAIL PROTECTED]
Kineticode. Setting knowledge in motion.[sm]


Re: Perl Testing

2003-06-19 Thread Stas Bekman
David Wheeler wrote:
On Tuesday, June 17, 2003, at 08:02  PM, Stas Bekman wrote:
Geoffrey Young wrote:
1. The documentation is pretty lacking.

As Geoff pointed out, this statement is incorrect. The document:
http://perl.apache.org/docs/general/testing/testing.html
should answer most of your questions.

It's incorrect in the sense that most of the modules aren't documented. 
That's absolutely true. I thought you were referring to the tutorial.
I was using that article and the one on perl.com, or I would have got 
nowhere. I'll likely submit some docs for TestRequest shortly.
Fantastic. May I suggest that modules should include only API docs, but all 
real usages go to the tutorial? modperl-docs/src/general/testing/testing.pod

 2. The tests are being run from t/, rather then from the root of the
 module distribution directory. IIRC, Perl itself runs all of its tests
 from t/, but all modules by default run them from the module
 distribution root. Can this be fixed/changed?
They aren't running from t/, unless you run them from there. t/TEST 
can run from t/ and from base.

No, I run `make test`. In my test scripts, which live in t/, when I want 
to parse the log, I have to open 'logs/error_log', not 
't/logs/error_log'. It runs out of t/.
What you try to say is that the ServerRoot is t/, not that t/TEST is invoked 
from t/. You can override that of course.

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Re: Perl Testing

2003-06-19 Thread Geoffrey Young

No, I run `make test`. In my test scripts, which live in t/, when I 
want to parse the log, I have to open 'logs/error_log', not 
't/logs/error_log'. It runs out of t/.

What you try to say is that the ServerRoot is t/, not that t/TEST is 
invoked from t/. You can override that of course.

How?
I think he means by adding your own ServerRoot directive to 
extra.last.conf.in.  however, I see what you are saying and that won't 
likely resolve your issue.

is there some reason that you want to backtrack to t/ in your test scripts? 
 for the most part, I put things I need under t/, including libraries and 
other cruft, so that everything is relative to the default ServerRoot setting.

HTH
--Geoff


Re: Perl Testing

2003-06-18 Thread Stas Bekman
Geoffrey Young wrote:

1. The documentation is pretty lacking.
As Geoff pointed out, this statement is incorrect. The document:
http://perl.apache.org/docs/general/testing/testing.html
should answer most of your questions.
 2. The tests are being run from t/, rather then from the root of the
 module distribution directory. IIRC, Perl itself runs all of its tests
 from t/, but all modules by default run them from the module
 distribution root. Can this be fixed/changed?
They aren't running from t/, unless you run them from there. t/TEST can run 
from t/ and from base.

Look at how mod_perl does that.
BTW, autogeneration of t/TEST is only useful if you don't want any 
customizations. If you do, create t/TEST.PL, like modperl-2.0 does.

Another examples on CPAN are Apache::Peek and Apache::Clean.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Re: Perl Testing

2003-06-18 Thread David Wheeler
On Tuesday, June 17, 2003, at 08:02  PM, Stas Bekman wrote:
Geoffrey Young wrote:
1. The documentation is pretty lacking.
As Geoff pointed out, this statement is incorrect. The document:
http://perl.apache.org/docs/general/testing/testing.html
should answer most of your questions.
It's incorrect in the sense that most of the modules aren't documented. 
I was using that article and the one on perl.com, or I would have got 
nowhere. I'll likely submit some docs for TestRequest shortly.

 2. The tests are being run from t/, rather then from the root of the
 module distribution directory. IIRC, Perl itself runs all of its 
tests
 from t/, but all modules by default run them from the module
 distribution root. Can this be fixed/changed?

They aren't running from t/, unless you run them from there. t/TEST 
can run from t/ and from base.
No, I run `make test`. In my test scripts, which live in t/, when I 
want to parse the log, I have to open 'logs/error_log', not 
't/logs/error_log'. It runs out of t/.

Look at how mod_perl does that.
BTW, autogeneration of t/TEST is only useful if you don't want any 
customizations. If you do, create t/TEST.PL, like modperl-2.0 does.
I'll take a look.
Another examples on CPAN are Apache::Peek and Apache::Clean.
Thanks.
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED]  ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
   Jabber: [EMAIL PROTECTED]
Kineticode. Setting knowledge in motion.[sm]


Perl Testing

2003-06-17 Thread David Wheeler
Hi All,
I'm porting MasonX::CallbackHandler from Apache::test to Apache::Test. 
My Makefile.PL does this:

use Apache::TestMM qw(test clean);
use Apache::TestRunPerl;
Apache::TestMM::filter_args();
Apache::TestRunPerl-generate_script();
This is nice, because it creates t/TEST for me. But I've noticed a 
couple of issues that might be relevant to other folks porting from 
Apache::test:

1. The documentation is pretty lacking. Granted, it was bad in 
Apache::test, too, but I sure would like to see some decent pod in each 
of the important Apache::Test* modules.

2. The tests are being run from t/, rather then from the root of the 
module distribution directory. IIRC, Perl itself runs all of its tests 
from t/, but all modules by default run them from the module 
distribution root. Can this be fixed/changed?

3. Those of us porting from Apache::test typically have a special 
configuration file (now nicely able to be t/lib/extra.conf.in -- 
thanks!) and loads up the libraries we want to test. However, Apache 
isn't being started during `make test` with Cuse blib. Now, since 
tests run from t, even it it did Cuse blib, it wouldn't work. So I 
had to add this code to my extra.conf.in:

Perl
  use File::Spec::Functions qw(catdir);
  use lib catdir '@ServerRoot@', '..', 'blib';
  use lib catdir '@ServerRoot@', '..', 'lib';
/Perl
Could this, too, be fixed? Perhaps just for Perl modules?
TIA for your help/answers/corrections to my observations.
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED]  ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
   Jabber: [EMAIL PROTECTED]
Kineticode. Setting knowledge in motion.[sm]


Re: Perl Testing

2003-06-17 Thread Geoffrey Young

1. The documentation is pretty lacking. Granted, it was bad in 
Apache::test, too, but I sure would like to see some decent pod in each 
of the important Apache::Test* modules.
agreed.  resources you may find useful (if you haven't seen them already):
http://www.perl.com/pub/a/2003/05/22/testing.html
http://perl.apache.org/docs/general/testing/testing.html
there is also some good information in the README
http://search.cpan.org/src/STAS/Apache-Test-1.01/README

3. Those of us porting from Apache::test typically have a special 
configuration file (now nicely able to be t/lib/extra.conf.in -- 
thanks!) and loads up the libraries we want to test. However, Apache 
isn't being started during `make test` with Cuse blib. Now, since 
tests run from t, even it it did Cuse blib, it wouldn't work. So I had 
to add this code to my extra.conf.in:

Perl
  use File::Spec::Functions qw(catdir);
  use lib catdir '@ServerRoot@', '..', 'blib';
  use lib catdir '@ServerRoot@', '..', 'lib';
/Perl
for the most part, Apache-Test does the right thing.  the only exception I've noticed is 
for modules that use XS or otherwise need to be preloaded.  the solution for this is to to 
use t/conf/extra.last.conf.in in place of t/conf/extra.conf.in.  this allows Apache-Test 
to set the proper blib (via PerlRequre) before including modules from your configuration. 
 even if you don't use XS, this may solve your problem.

you can also extend libraries, etc, via t/conf/modperl_extra.pl
HTH
--Geoff