http-webtest-general — Web page testing using HTTP-WebTest

[Http-webtest-general] Re: Button_Click question

[Ilya M. <il...@ma...>]

>>>>> On Wed, 31 Jul 2002 07:54:29 -0400, "William McKee" <wi...@kn...> said:

WM> So Ilya says that it's impossible to tell the button_click which
WM> form to access. However, does the button_click work with multiple
WM> forms if the button names are unique? I'm having a problem getting
WM> the button_click to work in this kind of situation.

It *should* work. Beware that Click plugin is very new (thus probably
buggy) and all it does is setting url for next test. It DOESN'T sets
any cgi query parameters. You still have to do it yourself
with test parameter 'params.

I have plans to enchance this plugin. It will handle seting cgi query
parameters according content of form but it is not ready yet.

-- 
Ilya Martynov (http://martynov.org/)

[Http-webtest-general] Re: Using Click and Hooks

[Ilya M. <il...@ma...>]

>>>>> On Wed, 31 Jul 2002 07:47:57 -0400, "William McKee" <wi...@kn...> said:

WM> On 31 Jul 2002 at 12:20, Ilya Martynov wrote:
>> It is impossible right now. On the other hand it is not very hard to
>> add ability to tell HTTP::WebTest which form to use. I just not sure
>> about interface. How do you want to specify form to use? Form number
>> on page? Form name (given that you set it with name attribute)?

WM> I generally give my forms names when I have multiple forms on a
WM> page. So this would be the format that I'd prefer. Can you show me
WM> an example of how I would tell WebTest which form to use?

I'm not sure yet. Maybe another test parameter like form_name.
 
>> You can either set it in the perl script or in
>> on_request/on_response hooks in first test block. I have plans to
>> add additional hooks to be run at the begining and at the end of
>> test sequence.

WM> The create/destroy hooks sound like just the thing for the dbh
WM> situation. In the meantime, I was hoping to see an example of
WM> setting the dbh in a test block. When I pickup a cookbook, I
WM> expect complete recipes <g>. Unless I missed it, the recipe for
WM> querying a database is incomplete because it does not explain
WM> where the Test object came from.

There is not Test object. It just a variable in namespace of Test
package. If you run HTTP::WebTest from script you could initialize it
with

$Test::dbh = DBI->connect(...);

Actually you can use any namespace for variables you pass from Perl
script to wtscript.

Anyway you are right that this recipt is incomplete. I should rework
it and explain initialization.

P.S. BTW if you find yourself writing too much Perl code in wtscript
files you should consider writting you own plugins and moving your
Perl code into them. It is not very hard - look in sources of any of
default plugins in lib/HTTP/WebTest/Plugin.

-- 
Ilya Martynov (http://martynov.org/)

[Http-webtest-general] Button_Click question

[William M. <wi...@kn...>]

So Ilya says that it's impossible to tell the button_click which form 
to access. However, does the button_click work with multiple forms 
if the button names are unique? I'm having a problem getting the 
button_click to work in this kind of situation.

Thanks,
William
-- 
 Lead Developer
 Knowmad Services Inc. || Internet Applications & Database 
Integration
 http://www.knowmad.com
 

[Http-webtest-general] Re: Using Click and Hooks

[William M. <wi...@kn...>]

On 31 Jul 2002 at 12:20, Ilya Martynov wrote:
> It is impossible right now. On the other hand it is not very hard to
> add ability to tell HTTP::WebTest which form to use. I just not sure
> about interface. How do you want to specify form to use? Form number
> on page? Form name (given that you set it with name attribute)?

I generally give my forms names when I have multiple forms on a page. So this 
would be the format that I'd prefer. Can you show me an example of how I would tell 
WebTest which form to use?

 
> You can either set it in the perl script or in on_request/on_response
> hooks in first test block. I have plans to add additional hooks to be
> run at the begining and at the end of test sequence.

The create/destroy hooks sound like just the thing for the dbh situation. In the 
meantime, I was hoping to see an example of setting the dbh in a test block. When I 
pickup a cookbook, I expect complete recipes <g>. Unless I missed it, the recipe for 
querying a database is incomplete because it does not explain where the Test 
object came from.

Thanks,
William
 


-- 
 Lead Developer
 Knowmad Services Inc. || Internet Applications & Database Integration
 http://www.knowmad.com
 

[Http-webtest-general] Re: Using Click and Hooks

[Ilya M. <il...@ma...>]

>>>>> On Tue, 30 Jul 2002 22:12:59 -0400, "William McKee" <wi...@kn...> said:

MC> Greetings,

Hi William,

MC> Well, I've discovered the wonders of the click_button test
MC> parameter lately. That's a nice feature. A question: is it
MC> possible to tell HTTP::WebTest which form to use when clicking the
MC> button. I have a page with several forms that have a button with
MC> the same name. I can work around it but was curious.

It is impossible right now. On the other hand it is not very hard to
add ability to tell HTTP::WebTest which form to use. I just not sure
about interface. How do you want to specify form to use? Form number
on page? Form name (given that you set it with name attribute)?

MC> I have also begun to use the on_reponse hook to grab dynamic data
MC> from the tests.  I saw in the Cookbook under the "User-Defined
MC> Tests" section an example that reads from the database. The
MC> example uses a dbh in $Test::dbh. However, I didn't see how this
MC> value ever got set. Can someone provide some details? Do I set it
MC> up in the webtest script or in the perl script I use to begin the
MC> tests?

You can either set it in the perl script or in on_request/on_response
hooks in first test block. I have plans to add additional hooks to be
run at the begining and at the end of test sequence.

-- 
Ilya Martynov (http://martynov.org/)

[Http-webtest-general] Using Click and Hooks

[William M. <wi...@kn...>]

Greetings,

Well, I've discovered the wonders of the click_button test parameter lately. That's a 
nice feature. A question: is it possible to tell HTTP::WebTest which form to use 
when clicking the button. I have a page with several forms that have a button with 
the same name. I can work around it but was curious.

I have also begun to use the on_reponse hook to grab dynamic data from the tests. 
I saw in the Cookbook under the "User-Defined Tests" section an example that 
reads from the database. The example uses a dbh in $Test::dbh. However, I didn't 
see how this value ever got set. Can someone provide some details? Do I set it up 
in the webtest script or in the perl script I use to begin the tests?

Thanks,
William

-- 
 Lead Developer
 Knowmad Services Inc. || Internet Applications & Database Integration
 http://www.knowmad.com
 

[Http-webtest-general] Re: Wish list

[Ilya M. <il...@ma...>]

>>>>> On Thu, 25 Jul 2002 09:46:17 -0400, "William McKee" <wi...@kn...> said:

WM> On 25 Jul 2002 at 11:03, Ilya Martynov wrote:
>> There exists test parameter 'terse':

WM> From the description, I didn't think it would do what I wanted, but
WM> I tried it. Using the
WM> following tags:

WM> show_html = yes
WM> show_cookies = yes
WM> show_headers = yes
WM> terse = failed_only

WM> I still get all of the html, headers and cookies printed out for
WM> successful tests. I think what I'm asking for is a new option for
WM> the show_html, show_cookies, show_headers called 'failed_only'
WM> which only prints these items in the case of a failed test. It's
WM> no big deal to sort throught the output of the successful tests or
WM> to add the show_* directives into the test that is failing, but it
WM> would be nice not to have to do that <g>.

Hmm. I think it is a bug. If terse = failed_only than html, cookies
and headers should be supressed in test report for successful tests.

I will change it unless anybody will raise his hand against it.

-- 
Ilya Martynov (http://martynov.org/)

Re: [Http-webtest-general] Re: Wish list

[William M. <wi...@kn...>]

On 25 Jul 2002 at 11:03, Ilya Martynov wrote:
> There exists test parameter 'terse':

From the description, I didn't think it would do what I wanted, but I tried it. Using the 
following tags:

show_html = yes
show_cookies = yes
show_headers = yes
terse = failed_only

I still get all of the html, headers and cookies printed out for successful tests. I think 
what I'm asking for is a new option for the show_html, show_cookies, show_headers 
called 'failed_only' which only prints these items in the case of a failed test. It's no 
big deal to sort throught the output of the successful tests or to add the show_* 
directives into the test that is failing, but it would be nice not to have to do that <g>.

As for the ability to include other templates, I didn't think it would be easy. I just 
wanted to add my vote to seeing a need for it should you or someone else on the 
list have the time and inclination to implement it. I'm very happy with the 
functionality of HTTP::WebTest as it is!

Thanks,
William

-- 
 Lead Developer
 Knowmad Services Inc. || Internet Applications & Database Integration
 http://www.knowmad.com
 

[Http-webtest-general] Re: Wish list

[Ilya M. <il...@ma...>]

>>>>> On Wed, 24 Jul 2002 19:32:29 -0400, "William McKee" <wi...@kn...> said:

Thanks for your kind words!

WM> Oops, I meant to include a couple of wish list items in the last
WM> email.

WM> 1. It'd be nice to only output the html, headers and cookies when
WM> a test fails instead of for every test. Is there any way to do
WM> that now or are there plans to add this ability? I know I can set
WM> it on a per test basis, but that's more time-consuming than paging
WM> through the html output of the successful tests.

There exists test parameter 'terse':

       terse

       Option to display shorter test report.

       o summary
           Only a one-line summary for each URL

       o failed_only
           Only tests that failed and the summary
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

       o no
           Show all tests and the summary

           Default value

           "no"

Is it what you are looking for?

WM> 2. It'd be nice to be able to include other test scripts into
WM> another. That way I could have a script that logs in to the server
WM> as an administrator which can then be called by the other test
WM> scripts which perform various admin functions. This would
WM> centralize the login (and admin password) to a single file and
WM> allow me to split out my tests into separate scripts which run
WM> faster if I only need to perform a certain group of tests.

I see that such feature could be useful.  Though I'm not sure how it
can be implemented yet but I'll try to implement it.

-- 
Ilya Martynov (http://martynov.org/)

[Http-webtest-general] Wish list

[William M. <wi...@kn...>]

Oops, I meant to include a couple of wish list items in the last email. 

1. It'd be nice to only output the html, headers and cookies when a test fails instead 
of for every test. Is there any way to do that now or are there plans to add this 
ability? I know I can set it on a per test basis, but that's more time-consuming than 
paging through the html output of the successful tests.

2. It'd be nice to be able to include other test scripts into another. That way I could 
have a script that logs in to the server as an administrator which can then be called 
by the other test scripts which perform various admin functions. This would 
centralize the login (and admin password) to a single file and allow me to split out 
my tests into separate scripts which run faster if I only need to perform a certain 
group of tests.

Thanks,
William
-- 
 Lead Developer
 Knowmad Services Inc. || Internet Applications & Database Integration
 http://www.knowmad.com
 

[Http-webtest-general] Kudos!

[William M. <wi...@kn...>]

Greetings Ilya,

I looked at your WebTest module about a year and a half ago when it was around 
v1.0x. I've recently been using 1.99 to do some testing of the web applications that 
I've been building. It's a pleasure to work with. You've done a great job!

Via a webtest script, I've been able to login as an administrator, add a new item to 
my database, find the id of the newly added item via a regex and use that value for 
future interactions with the site. The transparent handling of the authentication 
cookie is magical! Thanks and keep up the excellent work!

Best wishes,
William

-- 
 Lead Developer
 Knowmad Services Inc. || Internet Applications & Database Integration
 http://www.knowmad.com
 

[Http-webtest-general] Re: HTTP::WebTest and WAP sites

[Ilya M. <il...@ma...>]

>>>>> On Wed, 10 Jul 2002 10:39:45 -0700 (PDT), David Kirby <dk...@ya...> said:

DK> I'm trying to create a script that will test a dual purpose website that
DK> services both http and wap.  The webserver uses the User-Agent string to
DK> determine the type of page to return.

DK> Can anyone here help with sending the following User-Agent string
DK> so that the site thinks that the established session is with a wap
DK> handset?  (User-Agent: text/vnd.wap.wml)

David,

I've already answered you question. Have you got that email?

It is archived and is avialable from

    http://sourceforge.net/mailarchive/forum.php?thread_id=879251&forum_id=7376

If it is not clear enough fill free to ask further questions.

-- 
Ilya Martynov (http://martynov.org/)

[Http-webtest-general] HTTP::WebTest and WAP sites

[David K. <dk...@ya...>]

I'm trying to create a script that will test a dual purpose website that
services both http and wap.  The webserver uses the User-Agent string to
determine the type of page to return.

Can anyone here help with sending the following User-Agent string so that the
site thinks that the established session is with a wap handset?  (User-Agent:
text/vnd.wap.wml)

Thanks in advance for your help!
David Kirby
dk...@ya...

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

[Http-webtest-general] Re: WebTest Perl Module

[Ilya M. <il...@ma...>]

>>>>> On Wed, 10 Jul 2002 11:22:52 -0500, "Kirby, David" <Dav...@NM...> said:

DK> Ilya,

Hi Kirby,

Please post questions about HTTP-WebTest on its maillist so others can
benefit from answers.

DK> I'm wanting to use your WebTest script to test a WAP website and
DK> was wondering if your script would support giving the remote
DK> website a non-standard User-Agent string (i.e. text/vnd.wap.wml)
DK> for WAP?

If you use development version of HTTP-WebTest (avialable from
http://martynov.org/tgz/HTTP-WebTest-1.99_07.tar.gz) you can set
User-Agent string with test parameter 'user_agent'. Also you can set
any other HTTP header in test request using test
parameter 'http_headers'.

BTW are you sure that you need to set User-Agent header? Usually it is
not used to indicate requested content type. IIRC header Accept can be
used for this purpose.

-- 
Ilya Martynov (http://martynov.org/)

[Http-webtest-general] Re: HTTP-WebTest looking pretty solid now

[Ilya M. <il...@ma...>]

>>>>> On Wed, 19 Jun 2002 23:01:46 -0700, "Richard Anderson" <ri...@ri...> said:

RA> Hi Ilya.  After looking though the Changes log, it looks like
RA> version 1.99_* has had a good amount of real-world use and a lot
RA> of the obvious bugs have been fixed.  Maybe it's time to strip off
RA> the comment "THIS IS A BETA VERSION THAT IS A REWRITE OF VERSION
RA> 1.07 ..." from the docs?  When do you think it should be released
RA> as 2.0.0?

Then only thing stops me from releasing 2.0 is my plans to broke some
backward compatibility (with previous 1.99_xx releases). It is very
likely that I will made one more 1.99_xx release which does that and
unless there will be found any serious bugs it will be last 1.99_xx
release.

RA> After trying Parse::RecDescent, what is your opinion of it?  Are
RA> there any circumstances where you might use it for some other
RA> problem?

I dropped Parse::RecDescent because at some point I just could not get
it to report parsing errors correctly with last wtscript format
change. Moreover my previous (successful) attempts to make
Parse::RecDescent to do what I wanted it to to wasted a lot of my
time. When I rewrote parser in pure perl it took very small fraction
of time I've spent on Parse::RecDescent.

Would I use Parse::RecDescent in other projects? Well, I don't
know. Parse::RecDescent is powerful tool but it seems to be overkill
for simple grammars (wtscript grammar is definitely is quite
simple).

RA> As I recall, the default value of apache_options used to be -X,
RA> which seemed reasonable.  Why did you change this or is it not
RA> documented?

-X is implied now. You do not have to pass it via apache_options. The
reason for this change is that actualy HTTP::WebTest cannot work
correctly in local testing mode if Apache was started without this
parameter.

RA> I notice an item in TODO about cleaning up the code for local testing.  I
RA> always suspected that this was one of the least used options in the module.
RA> Have you ever received any queries / bug reports for this function?

Never. I highly suspect that actually nearly nobody uses this
option. Frankly even I've never used it myself with exception when I
was testing HTTP::WebTest::Plugin::Apache.

RA> Why do you need an error_log parameter?   The location of the error log is
RA> specified in the httpd.conf file in the temp directory that the module
RA> creates, so the error log will always be in the temp directory unless the
RA> user edits the module's httpd.conf file.

Well, it is needed because of ignore_error_log parameter. In general
case you may want to watch error log even if you don't run
HTTP-WebTest in local test mode. In this case there is no way how
HTTP-WebTest can deduce path to error_log.

Anyway in local test mode HTTP-WebTest does DWIM and error_log get's
"correct" default value.

RA> The docs say the allowed values of method are GET and PUT.  This
RA> should be GET and POST, yes?

Yes. Thanks for noticing it. To be fair I have never tried to do
through POD docs review so there are definetely some quirks in them.

It would be nice if someone volunteered to do this work. No matter how
hard I try my English will be always imperfect (live along technical
inaccuracies like this one).

-- 
Ilya Martynov (http://martynov.org/)

[Http-webtest-general] HTTP-WebTest looking pretty solid now

[Richard A. <ri...@ri...>]

Hi Ilya.  After looking though the Changes log, it looks like version 1.99_*
has had a good amount of real-world use and a lot of the obvious bugs have
been fixed.  Maybe it's time to strip off the comment "THIS IS A BETA
VERSION THAT IS A REWRITE OF VERSION 1.07 ..." from the docs?  When do you
think it should be released as 2.0.0?

After trying Parse::RecDescent, what is your opinion of it?  Are there any
circumstances where you might use it for some other problem?

As I recall, the default value of apache_options used to be -X, which seemed
reasonable.  Why did you change this or is it not documented?

I notice an item in TODO about cleaning up the code for local testing.  I
always suspected that this was one of the least used options in the module.
Have you ever received any queries / bug reports for this function?

Why do you need an error_log parameter?   The location of the error log is
specified in the httpd.conf file in the temp directory that the module
creates, so the error log will always be in the temp directory unless the
user edits the module's httpd.conf file.

The docs say the allowed values of method are GET and PUT.  This should be
GET and POST, yes?

Cheers,
Richard
ri...@ri...
www.richard-anderson.org
www.raycosoft.com

[Http-webtest-general] [ANNOUNCE] HTTP-WebTest 1.99_07

[Ilya M. <il...@ma...>]

The URL

    http://martynov.org/tgz/HTTP-WebTest-1.99_07.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/I/IL/ILYAM/HTTP-WebTest-1.99_07.tar.gz
  size: 86219 bytes
   md5: 9b4ac03b87d1ff659750f2efd93788ef


NAME
    HTTP::WebTest - Test remote URLs or local web files

DESCRIPTION

    This module runs tests on remote URLs or local web files
    containing Perl/JSP/HTML/JavaScript/etc. and generates a detailed
    test report.  This module can be used "as-is" or its functionality
    can be extended using plugins.  Plugins can define test types and
    provide additional report capabilities.  This module comes with a
    set of default plugins but can be easily extended with third party
    plugins.


1.99_07 Sun Jun 16 2002

ENHANCEMENTS:

* Non-core test parameters are included in POD documentation in
HTTP::WebTest.

* Added Bundle::HTTP::WebTest file which has list of all dependanices
including optional.

* $webtest->run_wtscript accepts wtscript passed as string.

* Parser for wtscript files is rewritten. It doesn't use
Parse::RecDescent anymore. New parser is faster and provides better
error diagnostics for parse errors.

INCOMPATIBILITIES:

* Changed syntax of wtscript files.  Parser of wtscript files expands
Perl variables in double quoted strings.

-- 
Ilya Martynov (http://martynov.org/)

[Http-webtest-general] Re: Multipart form data tests with HTTP::WebTest ?

[Ilya M. <il...@ma...>]

>>>>> On Fri, 14 Jun 2002 11:35:43 +0200, Jan Willamowius <ja...@mo...> said:

JW> Hi,

Hi Jan,

Please post questions about HTTP::Webtest to its maillist so others
can benfit from answers.

JW> I would like to use HTTP:WebTest to test image uploading. Is it
JW> possible to create tests with multipart form data ? I couldn't
JW> find anything in the POD.

Currently it is impossible. Support for file uploads have been in my
TODO for long time and probably I will add it soon.

-- 
Ilya Martynov (http://martynov.org/)

[Http-webtest-general] Re: webtest

[Marc R. <ma...@cl...>]

Id be happy to share it, and the netsaint / nagios configs I have created to
run it. You will probably want to tidy up my perl though, I am strictly an amateur
when it comes to coding (im working on it).

As soon as I have finished it, I will forward it to you so that you can clean it and
give it your approval before you drop it to the list.

The most significant thing that can be said about using your module instead of the
standard plugins, is because your module emulates a browser, the look and feel is much
closer to user activity, and this gives significantly less false posatives.



Marc




On Sun, Jun 09, 2002 at 01:08:07PM +0400, Ilya Martynov wrote:
> >>>>> On Sat, 8 Jun 2002 18:15:59 +0100, Marc Rogers <ma...@cl...> said:
> 
> MR> Many thanks for your reply, and my apologies for not posting the
> MR> query to the mailing list right away.
> 
> 
> MR> I am adapting your wt script for use with nagios/ netsaint as it
> MR> is much much more accurate for monitoring than the standard binary
> MR> "check_web" plungin thats commonly used.
> 
> If you came up with generic netsaint plugin and if you don't mind
> sharing it please send it me. I will include it in HTTP-WebTest distro
> in contrib section.
> 
> One HTTP-WebTest user already have sent me his netsaint plugin but it
> was too specialized to his tasks and I had not time to clean up it.
> 
> BTW if someone has plugins based on HTTP::WebTest for similar server
> monitoring software (spong, Net Sister, etc) and don't mind sharing it
> I also interested in seeing it.
> 
> -- 
> Ilya Martynov (http://martynov.org/)

[Http-webtest-general] Re: webtest

[Ilya M. <il...@ma...>]

>>>>> On Sat, 8 Jun 2002 18:15:59 +0100, Marc Rogers <ma...@cl...> said:

MR> Many thanks for your reply, and my apologies for not posting the
MR> query to the mailing list right away.


MR> I am adapting your wt script for use with nagios/ netsaint as it
MR> is much much more accurate for monitoring than the standard binary
MR> "check_web" plungin thats commonly used.

If you came up with generic netsaint plugin and if you don't mind
sharing it please send it me. I will include it in HTTP-WebTest distro
in contrib section.

One HTTP-WebTest user already have sent me his netsaint plugin but it
was too specialized to his tasks and I had not time to clean up it.

BTW if someone has plugins based on HTTP::WebTest for similar server
monitoring software (spong, Net Sister, etc) and don't mind sharing it
I also interested in seeing it.

-- 
Ilya Martynov (http://martynov.org/)

[Http-webtest-general] Re: webtest

[Ilya M. <il...@ma...>]

>>>>> On Sun, 9 Jun 2002 8:39:57 +0000, Duncan Cameron <dca...@bc...> said:

DC> Along similar lines I am playing around with webtest as a client
DC> to a .Net server.

DC> Net uses a similar approach for passing state around by a hidden
DC> field in each form called '__VIEWSTATE'.  The webtest client has
DC> to include this hidden field in the parameters POSTed back to the
DC> server.  I've written a small webtest plugin to extract the
DC> viewstate from each response and add then add it as an extra
DC> parameter in each POST.  It's similar to the Click plugin but uses
DC> HTML::Form to extract the hidden field.

DC> If anyone's interested in seeing it then let me know.

Of course I'm interested in seeing it :)

BTW I had idea to add support for hidden fields in Click plugin. I
just had no time to do it.

-- 
Ilya Martynov (http://martynov.org/)

[Http-webtest-general] Re: webtest

[Duncan C. <dca...@bc...>]

On 2002-06-08 Ilya Martynov wrote:
>>>>>> On Sat, 08 Jun 2002 13:57:49 +0100, Marc Rogers <ma...@cl...> said:
>
>MR> Hi
>
>Hi,
>
>Please post questions about HTTP::Webtest to maillist so others can
>benfit from answers.
>
>MR> I have a minor issue with HTTP::Webtest.
>
>MR> Due ot the way a site i am working on manages sessions, I need to be
>MR> able ro insert a variable parameter into the middle of the test
>MR> url. This is becuase the site uses a jsp based session management
>MR> system which creates a unique context for the users session:
>
>MR> ie:  if the user is assigned a session of !caa8Dp1BzY, then his url will be:
>MR> http://site.url/!caa8Dp1BzY/login.jsp
>
>MR> now I can easily capture the session id using the id example in your
>MR> cookbook, and pass this to a parameter, but I cant seem to insert it
>MR> into the url. I assume this is parsed and thrown out to the user
>MR> agent. is there any contingency for this in the module, or am I going
>MR> to have to hack it in?
>
>As I understand you are using latest development release (1.99_06).
>
>Something like
>
>test_name = Login
>    url = { "http://site.url/$SESSION_ID/login.jsp" }
>    ...
>    ...
>end_test
>
>should work (assuming that $SESSION_ID contains session id captured
>earlier).
>
>Note that just
>
>    url = "http://site.url/$SESSION_ID/login.jsp"
>
>doesn't work. You have to put string into curly braket to force
>evalutaion of Perl variables in string.
>
>Actually it is already changed in CVS and with CVS version
>
>    url = "http://site.url/$SESSION_ID/login.jsp"
>
>does works. I'm going to release it as soon as I fix bugs introduced
>by rewrite of parser.
>
>-- 
>Ilya Martynov (http://martynov.org/)
>
Along similar lines I am playing around with webtest as a client to a .Net server.

Net uses a similar approach for passing state around by a hidden field in each form
called '__VIEWSTATE'.  The webtest client has to include this hidden field in the
parameters POSTed back to the server.  I've written a small webtest plugin to extract
the viewstate from each response and add then add it as an extra parameter in 
each POST.  It's similar to the Click plugin but uses HTML::Form to extract the
hidden field.

If anyone's interested in seeing it then let me know.

Regards,
Duncan Cameron

[Http-webtest-general] Re: webtest

[Marc R. <ma...@cl...>]

Many thanks for your reply, and my apologies for not posting the
query to the mailing list right away.


I am adapting your wt script for use with nagios/ netsaint as it
is much much more accurate for monitoring than the standard binary
"check_web" plungin thats commonly used.

Again, thanks for the help and thanks for the module guys.


Marc

[Http-webtest-general] Re: webtest

[Ilya M. <il...@ma...>]

>>>>> On Sat, 08 Jun 2002 13:57:49 +0100, Marc Rogers <ma...@cl...> said:

MR> Hi

Hi,

Please post questions about HTTP::Webtest to maillist so others can
benfit from answers.

MR> I have a minor issue with HTTP::Webtest.

MR> Due ot the way a site i am working on manages sessions, I need to be
MR> able ro insert a variable parameter into the middle of the test
MR> url. This is becuase the site uses a jsp based session management
MR> system which creates a unique context for the users session:

MR> ie:  if the user is assigned a session of !caa8Dp1BzY, then his url will be:
MR> http://site.url/!caa8Dp1BzY/login.jsp

MR> now I can easily capture the session id using the id example in your
MR> cookbook, and pass this to a parameter, but I cant seem to insert it
MR> into the url. I assume this is parsed and thrown out to the user
MR> agent. is there any contingency for this in the module, or am I going
MR> to have to hack it in?

As I understand you are using latest development release (1.99_06).

Something like

test_name = Login
    url = { "http://site.url/$SESSION_ID/login.jsp" }
    ...
    ...
end_test

should work (assuming that $SESSION_ID contains session id captured
earlier).

Note that just

    url = "http://site.url/$SESSION_ID/login.jsp"

doesn't work. You have to put string into curly braket to force
evalutaion of Perl variables in string.

Actually it is already changed in CVS and with CVS version

    url = "http://site.url/$SESSION_ID/login.jsp"

does works. I'm going to release it as soon as I fix bugs introduced
by rewrite of parser.

-- 
Ilya Martynov (http://martynov.org/)

[Http-webtest-general] [ANNOUNCE] HTTP-WebTest 1.99_06

[Ilya M. <il...@ma...>]

The URL

    http://martynov.org/tgz/HTTP-WebTest-1.99_06.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/I/IL/ILYAM/HTTP-WebTest-1.99_06.tar.gz
  size: 83511 bytes
   md5: 48d6e0716a0140bdcca38b49468ab844



NAME
    HTTP::WebTest - Test remote URLs or local web files

DESCRIPTION

    This module runs tests on remote URLs or local web files
    containing Perl/JSP/HTML/JavaScript/etc. and generates a detailed
    test report.  This module can be used "as-is" or its functionality
    can be extended using plugins.  Plugins can define test types and
    provide additional report capabilities.  This module comes with a
    set of default plugins but can be easily extended with third party
    plugins.



1.99_06 Sun May 12 2002

ENHANCEMENTS:

* New core test parameter 'http_headers'.  Allows to add additional
HTTP headers to HTTP request or override default HTTP headers in HTTP
request.  Thanks to Duncan Cameron for patch.

* New plugin HTTP::WebTest::Plugin::Click.  This plugin allows to use
names of links and button on HTML pages to build test requests.

BUG FIXES:

* Set Content-type to 'application/x-www-form-urlencoded' for POST.
Fixed for second time.  Apparently code to do this was lost during
HTTP-WebTest rewrite.  Thanks to Duncan Cameron for patch.


-- 
Ilya Martynov (http://martynov.org/)