Re: Perl Testing
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
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
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
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
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
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
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]
Re: Perl Testing
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