Stas Bekman wrote:
[...]
But that's exactly what is happening. Test::Harness runs only only the
client side, it actually runs the clients. Test::Harness in the A-T
setup has no idea the server side exists at all. The server side can
run ok/skip/etc via Test, Test::More, Apache::Test, etc. it th
Geoffrey Young wrote:
now, Apache-Test gets tricky. it _also_ makes sure that the server
response
gets funneled to Test::Harness if you use the plan $r, tests => 9 syntax
I think this makes it sound trickier than it needs to; AIUI the feeding the
results back to Test::Harness is nothing to do wit
>> now, Apache-Test gets tricky. it _also_ makes sure that the server
>> response
>> gets funneled to Test::Harness if you use the plan $r, tests => 9 syntax
> I think this makes it sound trickier than it needs to; AIUI the feeding the
> results back to Test::Harness is nothing to do with what s
On 20/01/2004, at 2:48 AM, Geoffrey Young wrote:
So let me see if I follow you. The request script is the client and
should output the test results. The response handler is handling the
server-side requests. It can send information back to the client to
output. It looked, though, like Geoff was usi
> I would appreciate some recommendations
> for books that explain the big picture view of testing. Have any titles
> on your bookshelf that you'd suggest for someone like myself? I don't
> know of any books that discuss testing specifically from a Perl
> perspective. Do you?
ORA had one in the wo
> So let me see if I follow you. The request script is the client and
> should output the test results. The response handler is handling the
> server-side requests. It can send information back to the client to
> output. It looked, though, like Geoff was using examples such as plan
> $r, tests=>9
On Mon, Jan 19, 2004 at 09:25:35AM +1300, Nick Phillips wrote:
> It seems you are going through pretty much what I did a month or two
> ago.
I'm glad to hear it's not just me!
> And eventually Stas said something that triggered that in me, too. But
> I do think that a better tutorial document
On 17/01/2004, at 4:12 PM, Stas Bekman wrote:
Geoffrey Young wrote:
[...]
I'd like to second Geoff comments on the fact that it's a complex
stuff. And we are here to help. And you are here to remember/write
down all the unclear things and help improve the docs so the next time
you need to do it
Hi...
It seems you are going through pretty much what I did a month or two
ago.
http://perl.apache.org/docs/general/testing/
testing.html#Developing_Response_and_Request_Parts_of_a_Test
Thanks. I overlooked that the first time and am now getting
documentation blindness. It seems that the sectio
On Sun, Jan 18, 2004 at 10:57:25AM -0500, Geoffrey Young wrote:
> it really depends on what you're trying to accomplish. Apache-Test is for
> what is generally called 'unit tests' or 'functional tests' - given known
> input, make sure your code gives you the correct output.
Now that you mention i
>>well, it's important if you're writing an API, not merely testing CGI
>>scripts or the like. for instance, suppose you have a class that subclasses
>>mod_perl. if you plan'd and ok'd things from a PerlHandler then you could
>>do things like
>>
>> isa_ok($r, 'My::Class');
>>
>>which you can't
On Sun, Jan 18, 2004 at 12:38:15AM -0800, Stas Bekman wrote:
> >William, the cvs version of Apache-Test now has this bug solved. So if
> >you want to use that APACHE solution try it. Though the suggested above
> >solution is more efficient, as it won't reconfigure the test suite on
> >every t/TE
On Sat, Jan 17, 2004 at 02:35:17PM -0500, Geoffrey Young wrote:
> cool. actually, I've been meaning for a while to create a :testmore import
> target that exports everything but ok() and plan() (the two that collide
> with Test::More).
That'd be very useful!
> well, it's important if you're wr
Stas Bekman wrote:
William, the cvs version of Apache-Test now has this bug solved. So if
you want to use that APACHE solution try it. Though the suggested above
solution is more efficient, as it won't reconfigure the test suite on
every t/TEST run.
Though I've also changed the env variables in
Stas Bekman wrote:
Stas Bekman wrote:
I've reproduced the problem:
setenv APACHE /home/stas/httpd/1.3-dynamic/bin/httpd
t/TEST -v -trace=debug -port select
t/TEST -v -trace=debug
one the first run, extra.conf.in is parsed:
Including /tmp/bug-reporting-skeleton-mp1/t/conf/extra.conf config file
gene
> I see why you call this code magical. It's definitely a step beyond my
> understanding and probably beyond my needs for now.
:)
> OK, I'm beginning to see now. I was able to take my revised skeleton and
> replace Apache::Test with Test::More. I had to modify the plan line to
> remove the have
On Sat, Jan 17, 2004 at 09:59:03AM -0500, Geoffrey Young wrote:
> > There's one last piece that I'm still unclear on which your article did
> > not mention--reponse handlers. Is this where the two paths diverge? I'm
> > not sure that I see much difference between the way you do it and the
> > highl
>
> There's one last piece that I'm still unclear on which your article did
> not mention--reponse handlers. Is this where the two paths diverge? I'm
> not sure that I see much difference between the way you do it and the
> highly magical stuff.
well, that's the next step. instead of calling pl
> I like that idea very much. Take the running/working simple test suite
> and start adding your things on top and not the other way around. Geoff,
> do you feel like adding this idea somewhere in the top of the
> testing.pod doc?
sure. I'll come up with another skeleton instead, though - as wil
On Fri, Jan 16, 2004 at 07:23:11PM -0800, Stas Bekman wrote:
> Yes, just like the document explains. Have you read further down? It goes:
Sorry, I guess I missed that part. It's a big page.
> And then 4 hours later you posted another email with a list of
> problems/questions. So is that the fin
On Fri, Jan 16, 2004 at 02:30:45PM -0500, Geoffrey Young wrote:
> basically, there are two ways to approach Apache-Test: do it all yourself or
> let Apache-Test add some highly magical stuff. the article I wrote takes
> the first route - it assumes that you already know how to edit an httpd.conf
>
Stas Bekman wrote:
I've reproduced the problem:
setenv APACHE /home/stas/httpd/1.3-dynamic/bin/httpd
t/TEST -v -trace=debug -port select
t/TEST -v -trace=debug
one the first run, extra.conf.in is parsed:
Including /tmp/bug-reporting-skeleton-mp1/t/conf/extra.conf config file
generating conf/extra.c
I've reproduced the problem:
setenv APACHE /home/stas/httpd/1.3-dynamic/bin/httpd
t/TEST -v -trace=debug -port select
t/TEST -v -trace=debug
one the first run, extra.conf.in is parsed:
Including /tmp/bug-reporting-skeleton-mp1/t/conf/extra.conf config file
generating conf/extra.conf from
/tmp/bug-
William McKee wrote:
On Thu, Jan 15, 2004 at 05:08:39PM -0800, Stas Bekman wrote:
strange, I saw it once and could never reproduce it again. What is the
sequence of commands when you get it?
That is interesting. Right now, I'm playing with Geoff's
bug-reporting-skeleton-mp1 running my my Apache 1
William McKee wrote:
Also you may want to adopt the convention we use for other test suites,
where the response part of the test resides under t/response. So you
usually don't test the module as is, but you create a response handler that
tests it. But it doesn't have to be that way of course.
O
William McKee wrote:
On Fri, Jan 16, 2004 at 01:03:00PM -0500, William McKee wrote:
On Thu, Jan 15, 2004 at 04:24:41PM -0800, Stas Bekman wrote:
I don't have apache 1.3 with ssl so I can't test it. And it doesn't quite
work with apache/mp 2.0 because you have hardcoded mp1 API. Please see the
por
William McKee wrote:
On Thu, Jan 15, 2004 at 09:03:54PM -0800, Stas Bekman wrote:
I didn't commit this part. I'm not sure we want to duplicate the porting
guide in this document. Instead of duplicating things, I've added a section
telling that this document uses mp2 in examples and gave a pointer
William McKee wrote:
On Thu, Jan 15, 2004 at 05:08:39PM -0800, Stas Bekman wrote:
strange, I saw it once and could never reproduce it again. What is the
sequence of commands when you get it?
t/TEST -start
t/TEST -run-tests t/03_hostport.t
can't work alone, you need to tell the httpd or apxs locat
Geoffrey Young wrote:
[...]
I'd like to second Geoff comments on the fact that it's a complex stuff. And
we are here to help. And you are here to remember/write down all the unclear
things and help improve the docs so the next time you need to do it again
it'll be all milk chocolate sweety.
if
On Thu, Jan 15, 2004 at 05:08:39PM -0800, Stas Bekman wrote:
> strange, I saw it once and could never reproduce it again. What is the
> sequence of commands when you get it?
That is interesting. Right now, I'm playing with Geoff's
bug-reporting-skeleton-mp1 running my my Apache 1.3.29 server with
> Just starting to review this module but have a quick question about the
> layout. Why is the perl module in t/My/Bug.pm and not in lib/My/Bug.pm?
> In most projects, the modules to be tested are in lib/, no?
the module was made specifically for mod_perl bug reporting - mod_perl adds
ServerRoot
On Fri, Jan 16, 2004 at 02:30:45PM -0500, Geoffrey Young wrote:
> if you're feeling a bit overwhelmed but have Apache-Test installed, I'd
> suggest that you start with this
>
> http://perl.apache.org/~geoff/bug-reporting-skeleton-mp1.tar.gz
>
> examine it, run it, and get a feel for how the test
On Fri, Jan 16, 2004 at 02:30:45PM -0500, Geoffrey Young wrote:
> no, I'm sorry - I didn't mean to sound so harsh. it just seemed to me that
> this was becoming a very long thread comprised mostly of things that I knew
> were answered already. apparentlly, not clearly enough, though :)
Thanks fo
> Honestly, I am trying my best. The problems I am encountering are
> changing perspective from a cgi to a mod_perl framework which thus
> entails learning lots more about the Apache server than I've ever known
> before. My apologies if you think these questions are inane or
> off-topic.
no, I'm
On Fri, Jan 16, 2004 at 02:01:15PM -0500, Geoffrey Young wrote:
> you can use have_lwp() to check for LWP support. have_module() is handy too.
Thanks.
> > OK. FYI, I didn't see anything about this in the docs. I looked at the
> > t/ dir in Apache::Test and only see request.t and ping.t. The
> >
> Good point. Is the following correct:
>
> plan tests => 5, have 'LWP', 'Crypt::SSLeay';
>
you can use have_lwp() to check for LWP support. have_module() is handy too.
> OK. FYI, I didn't see anything about this in the docs. I looked at the
> t/ dir in Apache::Test and only see request.t
On Thu, Jan 15, 2004 at 09:03:54PM -0800, Stas Bekman wrote:
> I didn't commit this part. I'm not sure we want to duplicate the porting
> guide in this document. Instead of duplicating things, I've added a section
> telling that this document uses mp2 in examples and gave a pointer to the
> chap
On Fri, Jan 16, 2004 at 01:03:00PM -0500, William McKee wrote:
> On Thu, Jan 15, 2004 at 04:24:41PM -0800, Stas Bekman wrote:
> > I don't have apache 1.3 with ssl so I can't test it. And it doesn't quite
> > work with apache/mp 2.0 because you have hardcoded mp1 API. Please see the
> > porting do
On Thu, Jan 15, 2004 at 05:08:39PM -0800, Stas Bekman wrote:
> strange, I saw it once and could never reproduce it again. What is the
> sequence of commands when you get it?
>
> t/TEST -start
> t/TEST -run-tests t/03_hostport.t
>
> can't work alone, you need to tell the httpd or apxs location
On Thu, Jan 15, 2004 at 04:24:41PM -0800, Stas Bekman wrote:
> I don't have apache 1.3 with ssl so I can't test it. And it doesn't quite
> work with apache/mp 2.0 because you have hardcoded mp1 API. Please see the
> porting doc: http://perl.apache.org/docs/2.0/user/porting/porting.html
> http://p
William McKee wrote:
--- testing.pod.orig 2004-01-14 22:15:37.0 -0500
+++ testing.pod 2004-01-14 21:16:30.0 -0500
@@ -361,7 +358,7 @@
in order to try to detect as many problems as possible during the
testing process, it's may be useful to run tests in different orders.
-This if
Stas Bekman wrote:
Stas Bekman wrote:
William McKee wrote:
On Wed, Jan 14, 2004 at 08:41:01PM -0800, Stas Bekman wrote:
Cool, now I get the thing running.
Great. Are you getting any failures? Please read my notes in
testnotes.txt.
Yes. I will look at the failures soonish.
I don't have apache 1.
Stas Bekman wrote:
William McKee wrote:
On Wed, Jan 14, 2004 at 08:41:01PM -0800, Stas Bekman wrote:
Cool, now I get the thing running.
Great. Are you getting any failures? Please read my notes in
testnotes.txt.
Yes. I will look at the failures soonish.
I don't have apache 1.3 with ssl so I can't
William McKee wrote:
On Wed, Jan 14, 2004 at 08:41:01PM -0800, Stas Bekman wrote:
Cool, now I get the thing running.
Great. Are you getting any failures? Please read my notes in
testnotes.txt.
Yes. I will look at the failures soonish.
What is this diff? Should I apply it
against [1]? Why not just
On Wed, Jan 14, 2004 at 08:41:01PM -0800, Stas Bekman wrote:
> Cool, now I get the thing running.
Great. Are you getting any failures? Please read my notes in
testnotes.txt.
> What is this diff? Should I apply it
> against [1]? Why not just update your snapshot?
Sorry, this is against the test
William McKee wrote:
On Wed, Jan 14, 2004 at 11:21:13AM -0800, Stas Bekman wrote:
and Apache::Test->config in perl files:
my $dir = catdir Apache::Test::config()->{vars}->{documentroot}, '...',
We need better docs for this configuration issue. Patches are very
welcome.
I'm not sure I follow your
On Wed, Jan 14, 2004 at 11:21:13AM -0800, Stas Bekman wrote:
> >>and Apache::Test->config in perl files:
> >>my $dir = catdir Apache::Test::config()->{vars}->{documentroot}, '...',
> >>
> >>We need better docs for this configuration issue. Patches are very
> >>welcome.
> >
> >
> >I'm not sure I fo
On Wed, Jan 14, 2004 at 05:02:39PM -0800, Stas Bekman wrote:
> >You are right, I don't need to include the 'use lib' statement in the
> >modperl_extra.pl file. I don't even need to use my module (e.g.
> >Apache::TestTest). I was just trying to follow the documentation at
> >perl.apache.org and appl
William McKee wrote:
[...]
And again I don't understand why do you need to add 'lib' when it's already
added with APACHE_TEST_LIVE_DEV=1, look at your modperl_startup.pl it
should be there.
You are right, I don't need to include the 'use lib' statement in the
modperl_extra.pl file. I don't even
On Wed, Jan 14, 2004 at 04:25:25PM -0800, Stas Bekman wrote:
> >I figured as much. So it seems that the only solution for loading
> >modules under mp1 is via modperl_extra.in.
>
> s/modperl_extra.in/modperl_extra.pl/
That's what I meant to say :/.
> It's not the best if you need to handle bot
William McKee wrote:
On Wed, Jan 14, 2004 at 03:43:59PM -0800, Stas Bekman wrote:
OK, I'm working on this conversion and am hitting a roadblock due to mp1
not supporting the PerlSwitches directive.
No need to:
That's a nice solution for enabling taintmode and warnings, but I was
referring to addi
On Wed, Jan 14, 2004 at 03:43:59PM -0800, Stas Bekman wrote:
> >OK, I'm working on this conversion and am hitting a roadblock due to mp1
> >not supporting the PerlSwitches directive.
>
> No need to:
That's a nice solution for enabling taintmode and warnings, but I was
referring to adding the pat
William McKee wrote:
On Wed, Jan 14, 2004 at 11:03:12AM -0800, Stas Bekman wrote:
William, you need to move the config files from conf to t/conf and make
them test.conf.in and test-ssl.conf.in. usually people put ssl into a
separate directory, so you will probably want to do:
t/conf/extra.conf.i
On Wed, Jan 14, 2004 at 11:03:12AM -0800, Stas Bekman wrote:
> William, you need to move the config files from conf to t/conf and make
> them test.conf.in and test-ssl.conf.in. usually people put ssl into a
> separate directory, so you will probably want to do:
>
> t/conf/extra.conf.in
> t/conf/
William McKee wrote:
On Wed, Jan 14, 2004 at 11:03:12AM -0800, Stas Bekman wrote:
William, you need to move the config files from conf to t/conf and make
them test.conf.in and test-ssl.conf.in.
My original goal in putting them in conf was to be able to reuse the
configuration directives for both
On Wed, Jan 14, 2004 at 11:03:12AM -0800, Stas Bekman wrote:
> William, you need to move the config files from conf to t/conf and make
> them test.conf.in and test-ssl.conf.in.
My original goal in putting them in conf was to be able to reuse the
configuration directives for both testing and produ
William McKee wrote:
On Wed, Jan 14, 2004 at 10:51:56AM -0800, Stas Bekman wrote:
Thanks William, but your package has a problem - it uses hardwired paths
(/home/william/perl/Apache-TestTest) , which obviously prevent me (or
anybody else) from using it. You need to use: @ServerRoot@, @DocumentRoo
On Wed, Jan 14, 2004 at 10:51:56AM -0800, Stas Bekman wrote:
> Thanks William, but your package has a problem - it uses hardwired paths
> (/home/william/perl/Apache-TestTest) , which obviously prevent me (or
> anybody else) from using it. You need to use: @ServerRoot@, @DocumentRoot@
> and other
William, you need to move the config files from conf to t/conf and make them
test.conf.in and test-ssl.conf.in. usually people put ssl into a separate
directory, so you will probably want to do:
t/conf/extra.conf.in
t/conf/test.conf.in
t/conf/ssl/test.conf.in
conf/startup.pl needs to be t/conf/m
William McKee wrote:
On Thu, Jan 08, 2004 at 12:57:43PM -0800, Stas Bekman wrote:
It's really hard to guess what did you do. As suggested below if you could
create a sample package which reproduces the problem, upload it somewhere
and post the URL here, we could be much more helpful. You should b
On Fri, Jan 09, 2004 at 12:46:48PM -0800, Stas Bekman wrote:
> Yes, -debug is for debugging the server, not the test suite, so 'perl -d
> t/TEST' is correct. Though it seems that we don't reproduce the perl flags
> when doing exec. So try to change t/TEST to add -d at the end of the first
> line
On Thu, Jan 08, 2004 at 12:57:43PM -0800, Stas Bekman wrote:
> It's really hard to guess what did you do. As suggested below if you could
> create a sample package which reproduces the problem, upload it somewhere
> and post the URL here, we could be much more helpful. You should be able to
> cr
William McKee wrote:
[...]
I've been calling it as `perl -d t/TEST`. I have tried calling it using
`t/TEST -debug perl` but the debugger hangs or, more recently, I get the
message '!!! server is not ready yet, try again.' Running the tests
without debugging or with the gdb debugger works fine. I ne
On Thu, Jan 08, 2004 at 12:57:43PM -0800, Stas Bekman wrote:
> It's really hard to guess what did you do. As suggested below if you could
> create a sample package which reproduces the problem, upload it somewhere
> and post the URL here, we could be much more helpful. You should be able to
> cr
William McKee wrote:
Hi all,
I'm still working on getting my test environment in place using
Apache::Test. Recently, I added a vhost section to my extra.conf.in
file. The test servers fire up as I would expect on ports 8529 and 8530
when I run `t/TEST -start`. However, following the instructions o
Hi all,
I'm still working on getting my test environment in place using
Apache::Test. Recently, I added a vhost section to my extra.conf.in
file. The test servers fire up as I would expect on ports 8529 and 8530
when I run `t/TEST -start`. However, following the instructions on the
perl.apache.or
66 matches
Mail list logo
