Hi John,
many thanks for the workaround, although I must confess I didn't understand
half of your reasoning behind it :)
Anyhow, it allowed me to upgrade Canoo and hopefully things will at one point
change within HttpUnit.
Ulrich
John Spann wrote:
Hi Ulrich,
Sadly, this limitation comes from a change in HTMLUnit and I haven't found a
clean way around it.
The problematic code is in WebClient's loadWebResponseInto method at line 415:
if (webResponse.getStatusCode() == HttpStatus.SC_NO_CONTENT) {
return webWindow.getEnclosedPage();
}
The Page stores the WebResponse, which StoreResponseCode uses to retrieve the
latest response code.
Instead of creating a new Page, HTMLUnit returns the previous page. To be
honest, I'm not sure how HTMLUnit should handle this. The current
implementation leaves the WebClient unchanged (the previous WebWindow is left
as the current response). They could have achieved this by creating a new Page
using the new WebReponse and the previous WebWindow to have the same effect
while maintaining the latest status code.
I've been leveraging WebTest's SelectWebClient and a Groovy step to ensure
requests resulting in a 204 are made in a WebClient that has no previous
response and then verify the response remains null after the request is made.
I know HTMLUnit will throw an error if it receives a failing status code, so
only a 204 should get me into this state. Here's what that looks like:
<selectWebClient description="Verify the status is 204 - No Content"
name="noContentRestClient">
<invoke method="DELETE" url="${my.url}/id/123"/>
<groovy description="There should be no current response from a Webtest
perspective">
assert step.getContext().getCurrentResponse() == null;
</groovy>
</selectWebClient>
In any case, this issue cannot be easily fixed by WebTest.
Cheers,
John Spann
Senior Software Engineer
Citrix Online | 7414 Hollister Avenue | Goleta, CA 93117
T: +1 805 690 3489 | M: +1 805 729 0008
[email protected]<x-msg://29/[email protected]>
http://www.citrixonline.com<http://www.citrixonline.com/>
[cid:[email protected]]
Access Your PC From Anywhere: www.gotomypc.com<http://www.gotomypc.com/>
Online Meetings Made Easy: www.gotomeeting.com<http://www.gotomeeting.com/>
Remote Support Made Easy: www.gotoassist.com<http://www.gotoassist.com/>
Webinars Made Easy: www.gotowebinar.com<http://www.gotowebinar.com/>
On May 8, 2012, at 11:18 PM, Marc Guillemot wrote:
Hi Ulrich,
you can activate the http header log by setting
log4j.logger.httpclient.wire.header=debug
in lib/log4j.properties
This will allow you to really "see" what WebTest receives from your
webserver.
Cheers,
Marc.
--
HtmlUnit support& consulting from the source
Blog: http://mguillem.wordpress.com
Le 08/05/2012 13:51, Ulrich Mayring a écrit :
Hello,
we have the following test:
<invoke method="DELETE" url="${my.url}/id/123"/>
<storeResponseCode property="status"/>
<verifyProperty name="status" text="204"/>
Canoo R1813 (the newest build) fails this test, whereas the older
release version 3.0.0 succeeds. The failure message on the report is:
expected value 204
actual value 200
Apparently Canoo erroneously thinks that the HTTP response code is 200.
We did verify that the HTTP response code is actually 204 (and the older
Canoo correctly identifies it as such).
The tested URL belongs to a REST API, i. e. the response is not HTML,
but XML.
Ulrich
_______________________________________________
WebTest mailing list
[email protected]<mailto:[email protected]>
http://lists.canoo.com/mailman/listinfo/webtest
_______________________________________________
WebTest mailing list
[email protected]
http://lists.canoo.com/mailman/listinfo/webtest
