[PATCH]Re: Apache::Test question
Hi,
this is quite an old thread. But now I have found why it was not working.
On Sunday 19 December 2004 23:34, Stas Bekman wrote:
Torsten Foertsch wrote:
On Thursday 16 December 2004 17:28, Stas Bekman wrote:
[...]
right, but the idea was to grep and jump to the code following it, which
brings us back to refresh().
While Apache::TestRunPerl::refresh is defined as:
#if Apache::TestRun refreshes config in the middle of configure
#we need to re-add modperl configure hooks
sub refresh {
my $self = shift;
$self-SUPER::refresh;
$self-configure_modperl;
}
and Apache::TestRun::refresh as:
#throw away cached config and start fresh
sub refresh {
my $self = shift;
$self-opt_clean(1);
$self-{conf_opts}-{save} = delete $self-{conf_opts}-{thaw} || 1;
$self-{test_config} = $self-new_test_config()-httpd_config;
$self-{test_config}-{server}-{run} = $self;
$self-{server} = $self-{test_config}-server;
}
At least the comments lead to the idea that refresh() is actually what I
want.
right, so see why the cache file is not updated? I think it's because it's
not saved and you still use the old config object.
Just so that you don't get mislead, Torsten, I'm not trying to figure out
what the problem is (at least not yet), hoping that you will. Since as far
as public API goes, everything works and refresh() is not a public API (at
least not yet). I was just trying to point you to where the solution might
be.
Let's start with a short explanation what I was trying to do. I wanted to test
a module with mod_ssl loaded in the first run and without it in the second
one. Hence my TEST.PL looks:
-
use strict;
use warnings FATAL = 'all';
use lib qw(lib);
use Apache::TestRunPerl ();
my $I=Apache::TestRunPerl-new;
my @[EMAIL PROTECTED]; # save
$I-run(@ARGV);
@[EMAIL PROTECTED]; # restore
Apache::TestConfig::autoconfig_skip_module_add('mod_ssl.c');
$I-refresh;
$I-run(@ARGV);
-
Both test runs work fine if put each in a separate TEST.PL. But I want them in
the same TEST.PL. To recreate the t/conf/httpd.conf between the runs
refresh() is called. Before the second run mod_ssl is skipped from the
configuration.
Now I also have to check whether mod_ssl is loaded from within my tests. I
tried to use need_module() for that.
What happens?
t/conf/httpd.conf is correctly recreated between the runs but need_module()
does not reflect the skipped module.
need_module() works on $cfg-{modules}. Hence this array must not contain
mod_ssl.
How is the configuration built?
I thought that calling t/TEST first inherits the configuration from an
existing httpd.conf and stores it into t/conf/apache_test_config.pm.
Subsequent calls from the actual tests the restore and use the cached
configuration.
But this was wrong particularly for the module list.
Apache::TestConfig::Parse::inherit_load_module() fetches the module list from
an existing httpd.conf. It is called once from t/TEST to generate
t/conf/httpd.conf and once for each test that uses the configuration. For
each test the inherited configuration is the merged with the cached one.
Hence, even if the cached configuration would reflect a skipped module the
one actually used by need_module would not anymore.
To avoid this problem I have introduced a new config attribute thawed that
is set in Apache::TestConfig::thaw. If it is set
Apache::TestConfig::Parse::inherit_load_module will immediately return
leaving the cached module list intact. That is not a satisfying solution
because there should be no need to inherit from a httpd.conf for each test.
The cached config should provide any information needed.
But a skipped module is not reflected even in the cached configuration. The
reason is the order of the should_kip_module-test and the inclusion in the
module list (also Apache::TestConfigParse::inherit_load_module). The patch
reverses that order.
The patch is against Apache::Test 1.22 that comes with RC5. All RC5 tests pass
with the patch applied.
I think it is worth to have an interface to do this kind of testing. Or is
there another way to get a module tested both with and without a particular
module loaded?
Of course there is still necessary a check for the compiled-in case.
Torsten
diff -Naur mod_perl-2.0.0-RC5/Apache-Test/lib/Apache/TestConfigParse.pm mod_perl-2.0.0-RC5.new/Apache-Test/lib/Apache/TestConfigParse.pm
--- mod_perl-2.0.0-RC5/Apache-Test/lib/Apache/TestConfigParse.pm 2005-04-14 14:20:29.0 +0200
+++ mod_perl-2.0.0-RC5.new/Apache-Test/lib/Apache/TestConfigParse.pm 2005-04-29 21:03:41.801355900 +0200
@@ -190,6 +190,7 @@
sub inherit_load_module {
my($self, $c, $directive) = @_;
+return if( $self-{thawed} );
for my $args (@{ $c-{$directive} }) {
my $modname = $args-[0];
my $file =
Re: Apache::Test question
On Thursday 16 December 2004 17:28, Stas Bekman wrote:
grep the source for reconfigure() which I think will enforce the re-cache.
Sorry, I could not find it. Simply changing refresh to reconfigure yields:
Can't locate object method reconfigure via package Apache::TestRunPerl at
/home/r2/work/Apache-ModSSL/t/TEST line 31.
Also grepping the source did not reveal something useful:
[EMAIL
PROTECTED]:/usr/lib/perl5/vendor_perl/5.8.5/i586-linux-thread-multi/Apache
grep -i reconfigure Test*.pm
TestConfig.pm:$self-{clean_level} = shift || 2; #2 == really clean, 1 ==
reconfigure
TestConfig.pm:# we probably could reconfigure on the fly
($self-configure), but
TestRun.pm:# reconfigure or not.
TestRun.pm:$self-{reconfigure} = $opts{configure} ||
TestRun.pm:if ($self-{reconfigure}) {
TestRun.pm:delete $self-{reconfigure};
TestRun.pm:#if config is cached and MaxClients == 1, must reconfigure
TestRun.pm:warning server is reconfigured for proxy;
While Apache::TestRunPerl::refresh is defined as:
#if Apache::TestRun refreshes config in the middle of configure
#we need to re-add modperl configure hooks
sub refresh {
my $self = shift;
$self-SUPER::refresh;
$self-configure_modperl;
}
and Apache::TestRun::refresh as:
#throw away cached config and start fresh
sub refresh {
my $self = shift;
$self-opt_clean(1);
$self-{conf_opts}-{save} = delete $self-{conf_opts}-{thaw} || 1;
$self-{test_config} = $self-new_test_config()-httpd_config;
$self-{test_config}-{server}-{run} = $self;
$self-{server} = $self-{test_config}-server;
}
At least the comments lead to the idea that refresh() is actually what I want.
Torsten
pgpHEK7B16bOs.pgp
Description: PGP signature
Re: Apache::Test question
Torsten Foertsch wrote:
On Thursday 16 December 2004 17:28, Stas Bekman wrote:
grep the source for reconfigure() which I think will enforce the re-cache.
Sorry, I could not find it. Simply changing refresh to reconfigure yields:
Sorry, I should have said just 'reconfigure', which is not a method. Just
to spot the code in charge to forcing reconfiguration.
Can't locate object method reconfigure via package Apache::TestRunPerl at
/home/r2/work/Apache-ModSSL/t/TEST line 31.
Also grepping the source did not reveal something useful:
[EMAIL
PROTECTED]:/usr/lib/perl5/vendor_perl/5.8.5/i586-linux-thread-multi/Apache
grep -i reconfigure Test*.pm
TestConfig.pm:$self-{clean_level} = shift || 2; #2 == really clean, 1 ==
reconfigure
TestConfig.pm:# we probably could reconfigure on the fly
($self-configure), but
TestRun.pm:# reconfigure or not.
TestRun.pm:$self-{reconfigure} = $opts{configure} ||
TestRun.pm:if ($self-{reconfigure}) {
TestRun.pm:delete $self-{reconfigure};
TestRun.pm:#if config is cached and MaxClients == 1, must reconfigure
TestRun.pm:warning server is reconfigured for proxy;
right, but the idea was to grep and jump to the code following it, which
brings us back to refresh().
While Apache::TestRunPerl::refresh is defined as:
#if Apache::TestRun refreshes config in the middle of configure
#we need to re-add modperl configure hooks
sub refresh {
my $self = shift;
$self-SUPER::refresh;
$self-configure_modperl;
}
and Apache::TestRun::refresh as:
#throw away cached config and start fresh
sub refresh {
my $self = shift;
$self-opt_clean(1);
$self-{conf_opts}-{save} = delete $self-{conf_opts}-{thaw} || 1;
$self-{test_config} = $self-new_test_config()-httpd_config;
$self-{test_config}-{server}-{run} = $self;
$self-{server} = $self-{test_config}-server;
}
At least the comments lead to the idea that refresh() is actually what I want.
right, so see why the cache file is not updated? I think it's because it's
not saved and you still use the old config object.
Just so that you don't get mislead, Torsten, I'm not trying to figure out
what the problem is (at least not yet), hoping that you will. Since as far
as public API goes, everything works and refresh() is not a public API (at
least not yet). I was just trying to point you to where the solution might be.
--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::Test question
On Wednesday 15 December 2004 20:46, Stas Bekman wrote:
Torsten Foertsch wrote:
But how do I know it in the tests? Is there another way except of
scanning conf/httpd.conf?
You do:
use Apache::Test;
plan tests = 5, need_module 'ssl';
It's documented in the Apache::Test manpage and also here:
http://perl.apache.org/docs/general/testing/testing.html
feel free to suggest an improvement if you couldn't find that information
when you read those docs. (you did read those, right? :)
yes, I did. I am aware of need_module() and have_module() being almost
the same thing. Now please have a look at Apache::ModSSL/t/1is_https.t
and TEST.PL:
TEST.PL:
---
...
my $I=Apache::TestRunPerl-new;
my @[EMAIL PROTECTED]; # save it
$I-run(@ARGV);
system cp t/conf/apache_test_config.pm t/conf/apache_test_config.pm1;
Apache::TestConfig::autoconfig_skip_module_add('mod_ssl.c');
$I-refresh;
$I-run(@argv);
system cp t/conf/apache_test_config.pm t/conf/apache_test_config.pm2;
---
For debugging I am duplicating the generated apache_test_config.pm files.
They do differ. The 2nd one lacks the LoadModule ssl_module as expected.
...
@@ -308,10 +308,6 @@
LoadModule rewrite_module /usr/lib/apache2-prefork/mod_rewrite.so
/IfModule
',
- 'IfModule !mod_ssl.c
-LoadModule ssl_module /usr/lib/apache2-prefork/mod_ssl.so
-/IfModule
-',
'IfModule !mod_unique_id.c
LoadModule unique_id_module /usr/lib/apache2-prefork/mod_unique_id.so
/IfModule
...
1is_https.t:
---
...
sub ssl_loaded {
open my $f, t/conf/httpd.conf or die ERROR: Cannot read t/conf/httpd.conf:
$!;
return grep(/^\s*LoadModule\s+ssl_module\b/, $f) ? 1 : 0;
}
...
#if( have_module('ssl') ) {
if( ssl_loaded ) {
plan tests = 2;
ok t_cmp( test( 'default', 'is_https' ), HAVE_SSL=1 is_https: 0\n, no ssl
);
ok t_cmp( test( 'SSL', 'is_https' ), HAVE_SSL=1 is_https: 1\n, ssl );
} else {
plan tests = 1;
ok t_cmp( test( 'default', 'is_https' ), HAVE_SSL= is_https: UNDEF\n, no
ssl );
}
---
My ssl_loaded() function distinguishes between the 2 cases, have_module('ssl')
does not. With have_module() always the 1st case is entered.
Here is an excerpt of Apache::Test:
sub need_module {
...
for (@modules) {
...
next if $cfg-{modules}-{$mod};
if (exists $cfg-{cmodules_disabled}-{$mod}) {
push @reasons, $cfg-{cmodules_disabled}-{$mod};
next;
}
...
}
...
}
Since my Apache::TestConfig in both cases contains mod_ssl.c in
$cfg-{modules} the test will succeed. The
Apache::TestConfig::autoconfig_skip_module_add('mod_ssl.c');
is disregarded while generating this hash.
Torsten
pgpQzmbM08pVZ.pgp
Description: PGP signature
Re: Apache::Test question
Torsten Foertsch wrote:
On Wednesday 15 December 2004 20:46, Stas Bekman wrote:
Torsten Foertsch wrote:
But how do I know it in the tests? Is there another way except of
scanning conf/httpd.conf?
You do:
use Apache::Test;
plan tests = 5, need_module 'ssl';
It's documented in the Apache::Test manpage and also here:
http://perl.apache.org/docs/general/testing/testing.html
feel free to suggest an improvement if you couldn't find that information
when you read those docs. (you did read those, right? :)
yes, I did. I am aware of need_module() and have_module() being almost
the same thing. Now please have a look at Apache::ModSSL/t/1is_https.t
and TEST.PL:
TEST.PL:
---
...
my $I=Apache::TestRunPerl-new;
my @[EMAIL PROTECTED]; # save it
$I-run(@ARGV);
system cp t/conf/apache_test_config.pm t/conf/apache_test_config.pm1;
Apache::TestConfig::autoconfig_skip_module_add('mod_ssl.c');
$I-refresh;
$I-run(@argv);
system cp t/conf/apache_test_config.pm t/conf/apache_test_config.pm2;
---
For debugging I am duplicating the generated apache_test_config.pm files.
They do differ. The 2nd one lacks the LoadModule ssl_module as expected.
...
@@ -308,10 +308,6 @@
LoadModule rewrite_module /usr/lib/apache2-prefork/mod_rewrite.so
/IfModule
',
- 'IfModule !mod_ssl.c
-LoadModule ssl_module /usr/lib/apache2-prefork/mod_ssl.so
-/IfModule
-',
'IfModule !mod_unique_id.c
LoadModule unique_id_module /usr/lib/apache2-prefork/mod_unique_id.so
/IfModule
...
1is_https.t:
---
...
sub ssl_loaded {
open my $f, t/conf/httpd.conf or die ERROR: Cannot read t/conf/httpd.conf:
$!;
return grep(/^\s*LoadModule\s+ssl_module\b/, $f) ? 1 : 0;
}
...
#if( have_module('ssl') ) {
if( ssl_loaded ) {
plan tests = 2;
ok t_cmp( test( 'default', 'is_https' ), HAVE_SSL=1 is_https: 0\n, no ssl
);
ok t_cmp( test( 'SSL', 'is_https' ), HAVE_SSL=1 is_https: 1\n, ssl );
} else {
plan tests = 1;
ok t_cmp( test( 'default', 'is_https' ), HAVE_SSL= is_https: UNDEF\n, no
ssl );
}
---
My ssl_loaded() function distinguishes between the 2 cases, have_module('ssl')
does not. With have_module() always the 1st case is entered.
Here is an excerpt of Apache::Test:
sub need_module {
...
for (@modules) {
...
next if $cfg-{modules}-{$mod};
if (exists $cfg-{cmodules_disabled}-{$mod}) {
push @reasons, $cfg-{cmodules_disabled}-{$mod};
next;
}
...
}
...
}
Since my Apache::TestConfig in both cases contains mod_ssl.c in
$cfg-{modules} the test will succeed. The
Apache::TestConfig::autoconfig_skip_module_add('mod_ssl.c');
is disregarded while generating this hash.
Right, because as you've figured out t/conf/apache_test_config.pm is a
cached version of the the test setup data. So you need to do a cleanup
before reconfiguring things so that file gets updated. Note that you
perform things A-T has no top-level support for at the moment. Since your
hack uses internal APIs it can break any moment if things change. So it's
important to provide a public API for this kind of purposes.
grep the source for reconfigure() which I think will enforce the re-cache.
--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::Test question
On Thu, Dec 16, 2004 at 11:28:42AM -0500, Stas Bekman wrote:
Right, because as you've figured out t/conf/apache_test_config.pm is a
cached version of the the test setup data. So you need to do a cleanup
before reconfiguring things so that file gets updated. Note that you
perform things A-T has no top-level support for at the moment. Since your
hack uses internal APIs it can break any moment if things change. So it's
important to provide a public API for this kind of purposes.
Hi Torsten,
This is an interesting approach you are using. I have opted for creating
a virtual server in my extra.conf.in config file called 'ssl' which
turns on mod_ssl in order to do my tests which require an ssl
connection. When I want to use the SSL connection in a request test, I
do the following:
my $config = Apache::Test::config();
Apache::TestRequest::module('ssl');
my $hostport = Apache::TestRequest::hostport();
I suppose this would not work for the automatically built response tests
which use the default port.
William
--
Knowmad Services Inc.
http://www.knowmad.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::Test question
William McKee wrote:
[...]
When I want to use the SSL connection in a request test, I
do the following:
my $config = Apache::Test::config();
Apache::TestRequest::module('ssl');
my $hostport = Apache::TestRequest::hostport();
BTW, A-T 1.17 has a new shortcut which does all the above:
$url = Apache::TestRequest::module2url('ssl');
I suppose this would not work for the automatically built response tests
which use the default port.
right, but you can't really run SSL tests with a manually coded client,
can you?
--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::Test question
Stas Bekman wrote:
William McKee wrote:
[...]
When I want to use the SSL connection in a request test, I
do the following:
my $config = Apache::Test::config();
Apache::TestRequest::module('ssl');
my $hostport = Apache::TestRequest::hostport();
BTW, A-T 1.17 has a new shortcut which does all the above:
$url = Apache::TestRequest::module2url('ssl');
cool.
I suppose this would not work for the automatically built response tests
which use the default port.
right, but you can't really run SSL tests with a manually coded client,
can you?
yes, you can. see the Live tests in Apache-SSLLookup.
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::Test question
William McKee wrote: On Thu, Dec 16, 2004 at 11:28:42AM -0500, Stas Bekman wrote: Right, because as you've figured out t/conf/apache_test_config.pm is a cached version of the the test setup data. So you need to do a cleanup before reconfiguring things so that file gets updated. Note that you perform things A-T has no top-level support for at the moment. Since your hack uses internal APIs it can break any moment if things change. So it's important to provide a public API for this kind of purposes. Hi Torsten, This is an interesting approach you are using. I have opted for creating a virtual server in my extra.conf.in config file called 'ssl' which turns on mod_ssl in order to do my tests which require an ssl connection. right. but keep in mind that's not the same thing - Torsten is testing an httpd both with and without mod_ssl _compiled_, which is very different than requests with and without ssl _enabled_, especially when you need to code internal logic around the presense of these optional functions. of course, if you're using mod_ssl compiled in statically the approach won't work, but it's admirable and required, allt he same. --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::Test question
Geoffrey Young wrote: I suppose this would not work for the automatically built response tests which use the default port. right, but you can't really run SSL tests with a manually coded client, can you? yes, you can. see the Live tests in Apache-SSLLookup. I'm not sure what do you mean, I've looked at http://search.cpan.org/src/GEOFF/Apache-SSLLookup-2.00_02/t/live/ and the client is there manually coded. -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::Test question
right, but you can't really run SSL tests with a manually coded client, ^ can you? yes, you can. see the Live tests in Apache-SSLLookup. I'm not sure what do you mean, I've looked at http://search.cpan.org/src/GEOFF/Apache-SSLLookup-2.00_02/t/live/ and the client is there manually coded. ^^^ but yes, I see that you meant the opposite, and you're right - you can't use autogenerated clients with server-side ssl tests, at least not that I was able to see. --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::Test question
Geoffrey Young wrote: right, but you can't really run SSL tests with a manually coded client, ^ can you? yes, you can. see the Live tests in Apache-SSLLookup. I'm not sure what do you mean, I've looked at http://search.cpan.org/src/GEOFF/Apache-SSLLookup-2.00_02/t/live/ and the client is there manually coded. ^^^ but yes, I see that you meant the opposite, and you're right - you can't use autogenerated clients with server-side ssl tests, at least not that I was able to see. Ah, oops, yes, I meant that :) I guess if your default server is somehow configured to run ssl, then it should work. remember that t/TEST has the -ssl option (I've never used it). -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::Test question
Torsten Foertsch wrote:
Hi,
I want my test suite run once with mod_ssl.so loaded and once without. My
TEST.PL looks this:
use strict;
use warnings FATAL = 'all';
use lib qw(lib);
use Apache::TestRunPerl ();
my $I=Apache::TestRunPerl-new;
$I-run(@ARGV);
Apache::TestConfig::autoconfig_skip_module_add('mod_ssl.c');
$I-refresh;
$I-run(@ARGV);
you probably want to copy @ARGV away and pass a copy, since run() mangles
it.
This works fine but I need to know in my handlers and in the tests itself what
case is running. For the handlers I set a variable in extra.conf.in:
IfModule mod_ssl.c
PerlSetVar HAVE_SSL 1
/IfModule
But how do I know it in the tests? Is there another way except of scanning
conf/httpd.conf?
You do:
use Apache::Test;
plan tests = 5, need_module 'ssl';
It's documented in the Apache::Test manpage and also here:
http://perl.apache.org/docs/general/testing/testing.html
feel free to suggest an improvement if you couldn't find that information
when you read those docs. (you did read those, right? :)
BTW, I don't think we have this technique documented anywhere, if you
could submit it as a patch to testing.pod that would be a great addition.
--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
