[Webtest] Displaying pages modified by Javascript in Webtest results

Dan T Dan T" <olafkolzig@gmail.com
Mon, 18 Dec 2006 11:34:10 -0500


------=_Part_12380_16126159.1166459650435
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Marc,

Thanks for the response. I agree it will probably get to be a burden to save
the response every single time, but some situations may call for doing
exactly that, and it would be useful for debugging too. Your proposal sounds
like exactly what I would want. If there was an attribute in the config
element like saveResponseOnSamePage with a default value of never and the
two options you mentioned, that would be perfect. Then dumpCurrentResponse
could be used to override the default behaviour within the test and save the
response anyways, if necessary.

I've noticed that when casting the response's enclosed page to an HtmlPage,
the asXml method returns the state of the page even with only attribute and
not DOM structure changes, so it is in fact possible to see the results of
individual steps without changing HtmlUnit. That's pretty neat. On the other
hand, casting is obviously not a very good solution, and I've noticed that
HtmlPage does not return the exact source of the page from the response but
modifies it slightly (I would guess to be more W3C/XHTML compliant),
including changing some tags without children from <tag></tag> to <tag/>.

Shawn,

As Marc said this requires modifying the Webtest source. You can try the
patch set with the changes I've mentioned here:
http://ca.geocities.com/olafkolzig@rogers.com/webtestpatch.txt . You'll need
to change webtest_home to whatever your webtest source directory is to apply
it with Eclipse or some other IDE. Keep in mind the comments above if you do
try it out though - this will save the response for every single step and it
will modify the source it receives as a response, so I would definitely not
recommend using this patch set regularly... it's more just to demonstrate
the behaviour. I'm not even sure if you can build Webtest and have it pass
the Junit tests with it either, since I'm just running off the class files.

On 12/16/06, Marc Guillemot <mguillemot@yahoo.fr> wrote:
>
> Hi Dan,
>
> I think that the possibility to save "the current state" of a page on
> the file system makes sens, particularly with the increased use of
> javascript on the client side.
> Nevertheless saving systematically the current state of the page after
> each action (setXxxx, clickXxxx) would cost time and place on the file
> system: for instance a 100 ko html page would be saved 16 times if 15
> fields are set on it (the original response + the 15 setXxxx steps). On
> the other side it may be sometimes useful to "see" the page state after
> a setXxx even if no DOM change has been triggered to understand which
> field has been set (for instance when fields are not easy to identify to
> be sure that the test took the right one).
>
> What about following:
> - add a step like <dumpCurrentResponse/> in WebTest allowing to
> explicitely save the current state of the current response to the file
> system (if I correctly remember this has already been mentioned on the
> mailing list)
> - provide the possibility to configure when the current state of a page
> has to be saved when no new page is loaded. I see currently following
> possibilities:
>    - never (what is currently done)
>    - on DOM structure change (ie when nodes are added or removed BUT not
> for instance when only form attribute values change). This could make
> sense as the default value.
>    - after each change in the html page (node added or removed as well
> as attributes changed.
>
> Marc.
> _______________________________________________
> WebTest mailing list
> WebTest@lists.canoo.com
> http://lists.canoo.com/mailman/listinfo/webtest
>

------=_Part_12380_16126159.1166459650435
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Marc,<br><br>Thanks for the response. I agree it will probably get to be a burden to save the response every single time, but some situations may call for doing exactly that, and it would be useful for debugging too. Your proposal sounds like exactly what I would want. If there was an attribute in the config element like saveResponseOnSamePage with a default value of never and the two options you mentioned, that would be perfect. Then dumpCurrentResponse could be used to override the default behaviour within the test and save the response anyways, if necessary. 
<br><br>I've noticed that when casting the response's enclosed page to an HtmlPage, the asXml method returns the state of the page even with only attribute and not DOM structure changes, so it is in fact possible to see the results of individual steps without changing HtmlUnit. That's pretty neat. On the other hand, casting is obviously not a very good solution, and I've noticed that HtmlPage does not return the exact source of the page from the response but modifies it slightly (I would guess to be more W3C/XHTML compliant), including changing some tags without children from &lt;tag&gt;&lt;/tag&gt; to &lt;tag/&gt;.
<br><br>Shawn,<br><br>As Marc said this requires modifying the Webtest source. You can try the patch set with the changes I've mentioned here: <a href="http://ca.geocities.com/olafkolzig@rogers.com/webtestpatch.txt">http://ca.geocities.com/olafkolzig@rogers.com/webtestpatch.txt
</a> . You'll need to change webtest_home to whatever your webtest source directory is to apply it with Eclipse or some other IDE. Keep in mind the comments above if you do try it out though - this will save the response for every single step and it will modify the source it receives as a response, so I would definitely not recommend using this patch set regularly... it's more just to demonstrate the behaviour. I'm not even sure if you can build Webtest and have it pass the Junit tests with it either, since I'm just running off the class files.
<br><br><div><span class="gmail_quote">On 12/16/06, <b class="gmail_sendername">Marc Guillemot</b> &lt;<a href="mailto:mguillemot@yahoo.fr">mguillemot@yahoo.fr</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Dan,<br><br>I think that the possibility to save &quot;the current state&quot; of a page on<br>the file system makes sens, particularly with the increased use of<br>javascript on the client side.<br>Nevertheless saving systematically the current state of the page after
<br>each action (setXxxx, clickXxxx) would cost time and place on the file<br>system: for instance a 100 ko html page would be saved 16 times if 15<br>fields are set on it (the original response + the 15 setXxxx steps). On
<br>the other side it may be sometimes useful to &quot;see&quot; the page state after<br>a setXxx even if no DOM change has been triggered to understand which<br>field has been set (for instance when fields are not easy to identify to
<br>be sure that the test took the right one).<br><br>What about following:<br>- add a step like &lt;dumpCurrentResponse/&gt; in WebTest allowing to<br>explicitely save the current state of the current response to the file
<br>system (if I correctly remember this has already been mentioned on the<br>mailing list)<br>- provide the possibility to configure when the current state of a page<br>has to be saved when no new page is loaded. I see currently following
<br>possibilities:<br>&nbsp;&nbsp; - never (what is currently done)<br>&nbsp;&nbsp; - on DOM structure change (ie when nodes are added or removed BUT not<br>for instance when only form attribute values change). This could make<br>sense as the default value.
<br>&nbsp;&nbsp; - after each change in the html page (node added or removed as well<br>as attributes changed.<br><br>Marc.<br>_______________________________________________<br>WebTest mailing list<br><a href="mailto:WebTest@lists.canoo.com">
WebTest@lists.canoo.com</a><br><a href="http://lists.canoo.com/mailman/listinfo/webtest">http://lists.canoo.com/mailman/listinfo/webtest</a><br></blockquote></div><br>

------=_Part_12380_16126159.1166459650435--