Loading ...
Sorry, an error occurred while loading the content.

[PATCH]Re: Apache::Test question

Expand Messages
  • Torsten Foertsch
    Hi, this is quite an old thread. But now I have found why it was not working. ... [...] ... Let s start with a short explanation what I was trying to do. I
    Message 1 of 14 , May 1, 2005
    • 0 Attachment

      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 @argv=@ARGV; # save

      @ARGV=@argv; # restore



      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

      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

      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

      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.

    Your message has been successfully submitted and would be delivered to recipients shortly.