I've tweaked the locator tests to take a string of expected values for
both windows and unix systems, so we can hard code what we expect for both
Steve Loughran wrote:
LocatorTest.testInternationalURI
Failure Expected file:/D:/L/u00f6wenbrau/aus/M/u00fcnchen to resolve
to /L\u00f6wenbrau/aus/M\u00fcnchen but got
D:\L\u00f6wenbrau\aus\M\u00fcnchen
expected:<[/L\u00f6wenbrau/aus/]M\u00fcnchen> but
was:<[D:\L\u00f6wenbrau\aus\]M\u00fcnchen>
again, the results look correct.
actuall
[junit] Testcase: testInternationalURI took 0.003 sec
[junit] FAILED
[junit] expected 0xf6 (\u00f6), but got 5c '\' expected:<246> but
was:<92>
[junit] junit.framework.AssertionFailedError: expected 0xf6
(\u00f6), but got 5c '\' expected:<246> but was:<92>
There was a bug in the tests here, we were double escaping the \u
symbol. I've fixed that and got the string being returned, so we now
test for the explicit unicode char coming back. Oh, and I handle the
current directory being stuck in ahead of the path by moving to relative
paths and prefixing the cwd in the comparison.
here's the new test, that passes on unix
public void testInternationalURI() throws Exception {
String result=assertResolves("L\u00f6wenbrau.aus.M\u00fcnchen");
char umlauted = result.charAt(1);
assertEquals("expected 0xf6 (\u00f6), but got
"+Integer.toHexString(umlauted)+" '"+umlauted+"'",
0xf6, umlauted);
}
The windows tests will still be failing with bad paths, but now we can
decide what the correct strings are and add them to the tests, then fix
any locator bugs that exist.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
