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/[EMAIL PROTECTED]/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 <[EMAIL PROTECTED]> 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 [email protected] http://lists.canoo.com/mailman/listinfo/webtest
