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.
Marc.
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?
_______________________________________________
WebTest mailing list
[email protected]
http://lists.canoo.com/mailman/listinfo/webtest
