[Webtest] Re: Webtest for JS and dynamic webpages

Marc Guillemot Marc Guillemot <mguillemot@yahoo.fr>
Mon, 16 Oct 2006 13:57:12 +0200

Hi Craig,

these tricks are very interesting. What about putting them in the Wiki 
(in a first time)? I suppose that such information is missing because 
none of the WebTest committers has a QA role like yours.

Some additional comments/questions:

1) you can use
<enableJavaScript .../>
to locally enable/disable javascript support

2) just curious: why do you need to set 
throwExceptionOnFailingStatusCode to false?

3) Not sure to really understand what is the aim of this. You want to 
verify the debug messages?

5) is perfect. This is exactly what allows to quickly understand and fix 
a problem.


Craig Copeland wrote:
> Howdy Amit,
> Yeah.  I have issues from time to time with webtest and JS.  Some have been bugs in HtmlUnit (the underlying browser) but most have been "bad" JavaScript or poor HTML on my side.  Being on the QA side of the house, sometimes I can't effect a change when the code succeeds for IE and FF, but fails for WebTest/HtmlUnit.  Therefore, I sometimes find the following tricks helpful:
> 1) In the config portion, use:
> ---
> <config ...>
>   <option name="JavaScriptEnabled" value="false" />
> </config>
> ---
> Of course, this is just disabling JS for your test run, but can be helpful from time to time.
> 2) With <webtest><steps> hierarchy use:
> ---
>         <groovy>
>           step.context.webClient.throwExceptionOnScriptError = true
>           step.context.webClient.throwExceptionOnFailingStatusCode = true
>         </groovy>
> ---
> Then you can re-enable these failure cases after you're past the troublesome code where HTML Unit is throwing exceptions or returning some failed status for HTML.  I typically use these settings independently depending on the situation I run into.
> 3) Some developers will use the "alert" function to dubug.  I've not found this tremendous helpful within WebTest.  Instead, I've found tweaking the JS code to write variable data, etc to the page itself can be helpful using something like:
> ---
> var variableInQuestion = ...;
> var tmp = getElementById("foo"); //A div tag, or something used on your page
> tmp.innerHTML = "foo = '" + tmp + "'";
> ---
> and then testing this with a webtest <verify... /> call or using the suggestion below in #4.
> 4) Again Within <webtest><steps>, use:
> ---
> <storeProperty propertyType="ant" property="foo" value="something you want to see" />
> <storeXPath propertyType="dynamic" property="bar" xpath="<some xpath expression like 'id(myElement)'>"
> <antWrapper>
>   <echo message="foo = '${foo}' and bar = '#{bar}' " />
> </antWrapper>
> ---
> which will give you output to your command terminal.
> 5) Probably the best suggestion and perhaps most helpful, is incrementally narrowing the scope of the problem.  I will typically create a new page on my local apache instance with the "broken" code first.  Then remove JS or HTML to narrow down where the problem might be.  Then once you've got the smallest possible code (and webtest), submit a question/comment to the list.  When you have an easy test to run, Marc, et al, can often run down your issue fairly quickly.
> These are my tricks.  I'm sure some of the others on the list have some that are better, but this is where I'm at currently.  Honestly, I'd love to have a quick list like this on the Canoo page with stuff like this from those guys that are smarter than me.
> Hope this helps,
> Craig
>> Now I am trying to make Webtest work against Java Script and against
>> dynamically generated webpages. Could you point me in the right
>> direction by giving me an idea of the Webtest keywords I should be
>> looking into?