As usual:
- WebTest 2.5 is quite old now. Have you tried with a recent build? With a recent build with a recent snapshot of HtmlUnit-1.14?
- do you have a publicly available website showing the problem?
I now see "Release 1641" in issue's title and 2,5 in affected version. Which one do you really use?
I'm using Release 1641. If there's a more recent build, or HtmlUnit 1.1.4 is available in a public Maven Repo - I can try upgrading.
You can pick latest HtmlUnit-1.14 snapshot from
http://build.canoo.com/htmlunit/artifacts/ and place it in your webtest lib dir in place of HtmlUnit-1.13.jar.
Do you know when HtmlUnit 1.14 will be released? Has it been tested with the latest version of Prototype?
HtmlUnit 1.14 will normally released this week. It integrates Prototype unit tests but not all are passing. Most of the one that fail should be irrelevant but...
Any update on this issue? Is there a release of WebTest that uses HtmlUnit 2.x yet?
WebTest uses HtmlUnit-2.1 since build 1700. Please tell me if the problem still exists (a publicly available url would be great)
I've successfully upgraded to R_1702 and Prototype 1.8.1. Works with everything but JSF. For some reason, the fileupload test passes with R_1600 and not R_1702.
http://issues.appfuse.org/browse/APF-946#action_12448
Matt
More on the JSF (MyFaces 1.2.2) issue...
Canoo WebTest causes the filename to be /Users/mraible/Work/appfuse-2.0/web/jsf/pom.xml, which is the same path that's in the input box when I do it through my browser. However, when I do it through the browser, file.getName() returns "pom.xml" instead of the full path. I can truncate the beginning of the path, but this seems like a regression bug in CWT.
With which browser do you test? If I correctly remember, HtmlUnit mimics browser's behaviour here and IE or FF sends the absolute file name, whereas the other sends only the file name without path.
I haven't configured any for CWT:
<config host="${host}" port="${port}" protocol="http"
basepath="${webapp.name}" resultpath="target/webtest-data" saveresponse="true"
resultfile="web-tests-result.xml" summary="true">
<header name="Accept-Language" value="${user.language}"/>
</config>
When I manually tested it, I used Firefox 3 on OS X.
My class does have this:
// APF-758: Fix for Internet Explorer's shortcomings
if (filename.indexOf("\\") != -1) {
int slash = filename.lastIndexOf("\\");
if (slash != -1) {
filename = filename.substring(slash + 1);
}
// Windows doesn't like /'s either
int slash2 = filename.lastIndexOf("/");
if (slash2 != -1) {
filename = filename.substring(slash2 + 1);
}
// In case the name is C:foo.txt
int slash3 = filename.lastIndexOf(":");
if (slash3 != -1) {
filename = filename.substring(slash3 + 1);
}
}
Adding the following before it is a workaround that works:
// APF-946: Canoo Web Tests R_1702 sets full path as name instead of only file name
if (filename.indexOf("/") > -1) {
filename = filename.substring(filename.lastIndexOf("/") + 1);
}
Have you tried with IE for Mac? My guess is that you would have the same thing than with WebTest.
I think that HtmlUnit correctly mimics IE's behaviour when running on windows (and has "\\" in filename), but when running on *nix, it has "\" as path separator. It would probably make sense for WebTest to allow to specify with which path a file should be uploaded. Please open a new issue for that if it makes sense for you.-
My only concern is that R_1600 would spit out the relative filename (pom.xml) whereas R_1702 spits out the absolute filename (/Users/mraible/Work/appfuse-2.0/web/jsf/pom.xml). I didn't change any code - the behavior is different between versions. I'm not too concerned about it since I figured out a workaround, but it seems like the former mimicked true browser behavior (of Firefox on OS X) more than the later.
If you don't configure any User-Agent header, your WebTest test will mimic Internet Explorer. If you configure a Firefox header, your WebTest will mimic Firefox and will for instance only send "pom.xml".