[Webtest] RE: Verifying URL components
Jerry Gaines
webtest@lists.canoo.com
Thu, 12 Sep 2002 22:35:10 +1000
----- Original Message -----
> From: "Dierk Koenig" <dierk.koenig@canoo.com>
> To: <webtest@lists.canoo.com>
> Subject: RE: [Webtest] Verifying URL components
> Date: Wed, 11 Sep 2002 11:58:22 +0200
> Reply-To: webtest@lists.canoo.com
>
> Hi Jerry,
>
> If all else fails, you can use verifytext with a regular expression.
> cf http://webtest.canoo.com/webtest/manual/syntax.html#9
>
> <verifytext stepid="Checks the server part of an href"
> text="<A.*?HREF=.*?http://myserver.com.*?>"
> regex="true" />
> [snip]
Hi Dierk,
Thanks for your reply. I had considered using verifylink, but the scenario
is one where you go to a page and that page then redirects you (either via a
META redirect element, or by the server sending a redirect response) to
another page. I would like to be able to test that the redirect succeeded,
without necessarily knowing anything about what's on the final destination
page.
Another, related scenario. In a Servlet 2.3 web application, you can define
a welcome file which will be served to the user when they request a
directory (using the <welcome-file-list> element of the deployment
descriptor). But, at least with the Tomcat 4.0.x appserver, this welcome
file gets served up via a redirect, so that the user enters
http://www.foobar.com, and then the address field changes to
http://www.foobar.com/index.html.
A customer of ours, however, has a requirement that the URL not change.
This is easy enough to do, but I want to test it. How do we verify that no
redirect took place? Is it possible to examine arbitrary headers in the
HTTP response, for instance? From JavaScript it's easy to get information
about the URL (window.location.href), but of course WebTest does not do
JavaScript.
So, thanks again for your reply -- in particular I had not paid attention to
the onsiteonly attribute of verifylinks, which on reflection looks like
quite a handy little feature -- but it did not really address the core
testing issue we've got.
Jerry