Re: Apache::TestRequest + Cookies
just a very simple test that verifies that the documented technique works. later on it may evolve to include a special A-T API if we ever add one. Is it enought to do IfModule mod_usertrack.c and also need_module(mod_usertrack.c) to determine if the usertrack mnodule is installed, or is there someplace deeper within the setup where we can actually add LoadModule mod_usertrack.c? Thanks, -=Chris
Re: Apache::TestRequest + Cookies
Christopher H. Laco wrote:
just a very simple test that verifies that the documented technique
works. later on it may evolve to include a special A-T API if we ever
add one.
Is it enought to do IfModule mod_usertrack.c and also
need_module(mod_usertrack.c) to determine if the usertrack mnodule is
installed, or is there someplace deeper within the setup where we can
actually add LoadModule mod_usertrack.c?
for config it's enough for the code it's:
plan tests = 5, need_module('usertrack');
but most people won't have this module installed...
--
__
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: Apache::TestRequest + Cookies
but most people won't have this module installed... Installed, or loaded? I know the httpd.conf defaults to having that module commented out, but the module itself should be around. Maybe relying on Apache::Session would cover more install scnerios instead. I was trying to avoid writing a custom handler just to accept and toss some cookies in the test environment, but maybe that's better. At least then everyone install should be able to run the A-T cookie test.
Re: Apache::TestRequest + Cookies
Christopher H. Laco wrote: but most people won't have this module installed... Installed, or loaded? I know the httpd.conf defaults to having that module commented out, but the module itself should be around. Loaded or even available... Maybe relying on Apache::Session would cover more install scnerios instead. I was trying to avoid writing a custom handler just to accept and toss some cookies in the test environment, but maybe that's better. At least then everyone install should be able to run the A-T cookie test. I think the same_interp setup will do what you want. e.g. see in modperl-2.0 repository this test couple: t/response/TestModperl/sameinterp.pm t/modperl/sameinterp.t -- __ 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: FW: Re: Apache::TestRequest + Cookies
CChristopher H. Laco wrote: Maybe relying on Apache::Session would cover more install scnerios instead. I was trying to avoid writing a custom handler just to accept and toss some cookies in the test environment, but maybe that's better. At least then everyone install should be able to run the A-T cookie test. I think the same_interp setup will do what you want. e.g. see in modperl-2.0 repository this test couple: t/response/TestModperl/sameinterp.pm t/modperl/sameinterp.t Yeah, I'll have to check that out. Thanks. (Yes, I just played the email switch-a-roo)
Re: FW: Re: Apache::TestRequest + Cookies
Christopher H. Laco wrote: Christopher H. Laco wrote: CChristopher H. Laco wrote: Maybe relying on Apache::Session would cover more install scnerios instead. I was trying to avoid writing a custom handler just to accept and toss some cookies in the test environment, but maybe that's better. At least then everyone install should be able to run the A-T cookie test. I think the same_interp setup will do what you want. e.g. see in modperl-2.0 repository this test couple: t/response/TestModperl/sameinterp.pm t/modperl/sameinterp.t Holy crap. That made my brain hurt. Would we use that directly, or just borrow the idea? Why don't you first post what you had on your mind. May be your idea doesn't need that at all. -- __ 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: FW: Re: Apache::TestRequest + Cookies
Stas Bekman wrote:
[snip]
Why don't you first post what you had on your mind. May be your idea
doesn't need that at all.
Well, here's what I was thinking. First, write a quick and dirty
mod_perl handler that looked for a specific cookie; let's say 'ApacheTest'.
If it wasn't supplied by the client, send a new copy out. If it was sent
by the client, simply return the supplied cookie/value.
Shouldn't take more than a few lines of code, and it removes the
dependency of usertrack and Apache::Session.
Then, simply write a test that makes a series of requests to that
handler. The first response should return a new ApacheTest cookie/value,
and the second test should pass back the same ApacheTest cookie/value if
Apache::TestRequest::user_agent( cookie_jar = {});
and it's surroundings are woroking fine.
-=Chris
Re: FW: Re: Apache::TestRequest + Cookies
Christopher H. Laco wrote:
Stas Bekman wrote:
[snip]
Why don't you first post what you had on your mind. May be your idea
doesn't need that at all.
Well, here's what I was thinking. First, write a quick and dirty
mod_perl handler that looked for a specific cookie; let's say 'ApacheTest'.
If it wasn't supplied by the client, send a new copy out. If it was sent
by the client, simply return the supplied cookie/value.
Shouldn't take more than a few lines of code, and it removes the
dependency of usertrack and Apache::Session.
Then, simply write a test that makes a series of requests to that
handler. The first response should return a new ApacheTest cookie/value,
and the second test should pass back the same ApacheTest cookie/value if
Apache::TestRequest::user_agent( cookie_jar = {});
and it's surroundings are woroking fine.
Sounds good. Though it'll probably need to leave in the modperl2's test
suite and not Apache-Test's one. but let's see the code first and then see
where it's the best to apply it. You can use the
http://perl.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz
to make it easy to write the test.
--
__
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: FW: Re: Apache::TestRequest + Cookies
Stas Bekman wrote: Sounds good. Though it'll probably need to leave in the modperl2's test suite and not Apache-Test's one. but let's see the code first and then see where it's the best to apply it. You can use the http://perl.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz to make it easy to write the test. I guess that's where I'm getting confused. Why would this be in mp2 rather than in A-T, since I'm really trying to confirm a scenerio under A-T. Obviously there's something I'm missing. -=Chris
Re: FW: Re: Apache::TestRequest + Cookies
Christopher H. Laco wrote: Stas Bekman wrote: Sounds good. Though it'll probably need to leave in the modperl2's test suite and not Apache-Test's one. but let's see the code first and then see where it's the best to apply it. You can use the http://perl.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz to make it easy to write the test. I guess that's where I'm getting confused. Why would this be in mp2 rather than in A-T, since I'm really trying to confirm a scenerio under A-T. Obviously there's something I'm missing. It should be in A-T, but since your test requires modperl it'd be better be in modperl, since chances are that A-T won't have modperl available and then it'll be skipped. So may be your original mod_usertrack idea was better, as it doesn't depend on mod_perl's availability (but at the same time depends on mod_usertrack). The reason I'm OK with adding A-T tests to modperl is that we run modperl2 tests all the time, much more often than A-T tests, so it's probably a second best place to put those cookie tests. In fact you can already find some cookie tests in the modperl2 test suite (against CGI.pm). -- __ 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: FW: Re: Apache::TestRequest + Cookies
Stas Bekman wrote: Christopher H. Laco wrote: Stas Bekman wrote: Sounds good. Though it'll probably need to leave in the modperl2's test suite and not Apache-Test's one. but let's see the code first and then see where it's the best to apply it. You can use the http://perl.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz to make it easy to write the test. I guess that's where I'm getting confused. Why would this be in mp2 rather than in A-T, since I'm really trying to confirm a scenerio under A-T. Obviously there's something I'm missing. It should be in A-T, but since your test requires modperl it'd be better be in modperl, since chances are that A-T won't have modperl available and then it'll be skipped. So may be your original mod_usertrack idea was better, as it doesn't depend on mod_perl's availability (but at the same time depends on mod_usertrack). Can't the test be done with mod_cgi and not mod_perl? This should be available more often than mod_usertrack I would think. -- Michael Peters Developer Plus Three, LP
Re: FW: Re: Apache::TestRequest + Cookies
Stas Bekman wrote: Michael Peters wrote: Stas Bekman wrote: Christopher H. Laco wrote: Stas Bekman wrote: Sounds good. Though it'll probably need to leave in the modperl2's test suite and not Apache-Test's one. but let's see the code first and then see where it's the best to apply it. You can use the http://perl.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz to make it easy to write the test. I guess that's where I'm getting confused. Why would this be in mp2 rather than in A-T, since I'm really trying to confirm a scenerio under A-T. Obviously there's something I'm missing. It should be in A-T, but since your test requires modperl it'd be better be in modperl, since chances are that A-T won't have modperl available and then it'll be skipped. So may be your original mod_usertrack idea was better, as it doesn't depend on mod_perl's availability (but at the same time depends on mod_usertrack). Can't the test be done with mod_cgi and not mod_perl? This should be available more often than mod_usertrack I would think. Yes, I was thinking the same. Good idea Michael. And it's enabled in the default shipping httpd.conf too! Great idea. I'll pursue it that method for now. -=Chris
Pickyness question
Just because I'm like that. :-)
I noticed in A-T/t/redirect.t we have:
plan tests = 6, need_module('mod_alias.c') need_lwp;
Of course, I noticed this after skimming over the A-T pod again , where
it mentions:
It's also important to mention to avoid using:
plan tests = 1, requirement1 requirement2;
For that matter, sometimes I see:
plan tests - 1, need_lwp;
plan tests - 1, need_lwp;
plan tests - 1, \need_lwp;
From a pure A-T coding standpoint, which is preferred?
-=Chris
Re: Pickyness question
Christopher H. Laco wrote:
Just because I'm like that. :-)
I noticed in A-T/t/redirect.t we have:
plan tests = 6, need_module('mod_alias.c') need_lwp;
Of course, I noticed this after skimming over the A-T pod again , where
it mentions:
It's also important to mention to avoid using:
plan tests = 1, requirement1 requirement2;
For that matter, sometimes I see:
plan tests - 1, need_lwp;
plan tests - 1, need_lwp;
plan tests - 1, \need_lwp;
From a pure A-T coding standpoint, which is preferred?
-=Chris
Sigh. Of course I meant:
plan tests = 1, need_lwp;
plan tests = 1, need_lwp;
plan tests = 1, \need_lwp;
Re: Pickyness question
Christopher H. Laco wrote:
Just because I'm like that. :-)
I noticed in A-T/t/redirect.t we have:
plan tests = 6, need_module('mod_alias.c') need_lwp;
Of course, I noticed this after skimming over the A-T pod again , where
it mentions:
It's also important to mention to avoid using:
plan tests = 1, requirement1 requirement2;
Yes, it's wrong, I will fix that. The doc is correct.
For that matter, sometimes I see:
1) plan tests = 1, need_lwp;
2) plan tests = 1, need_lwp;
3) plan tests = 1, \need_lwp;
From a pure A-T coding standpoint, which is preferred?
That's a totally different issue. Either 1 and 3 will work. since if it
gets a CODE ref it'll run it.
2 will also work but it's not the best way to call a function which
accepts not args, since when you call foo, @_ is passed to it (see
perlsub.pod)
NAME; # Makes current @_ visible to called subroutine.
so if it has an empty prototype, that would be an error.
--
__
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: svn commit: r109235 - /httpd/test/trunk/perl-framework/Apache-Test/t/redirect.t
-plan tests = 6, need_module('mod_alias.c') need_lwp;
+plan tests = 6, need need_module('mod_alias.c'), need_lwp;
^
?
:)
--Geoff
Re: svn commit: r109235 - /httpd/test/trunk/perl-framework/Apache-Test/t/redirect.t
Geoffrey Young wrote:
-plan tests = 6, need_module('mod_alias.c') need_lwp;
+plan tests = 6, need need_module('mod_alias.c'), need_lwp;
^
?
:)
--Geoff
Ha, now see what I've started. :-)
Re: svn commit: r109235 - /httpd/test/trunk/perl-framework/Apache-Test/t/redirect.t
Geoffrey Young wrote:
-plan tests = 6, need_module('mod_alias.c') need_lwp;
+plan tests = 6, need need_module('mod_alias.c'), need_lwp;
^
?
:)
Garbage in, garbage out :) now fixed :)
--
__
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
