ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: Bugs in release branch
Date Thu, 01 Nov 2007 15:02:51 GMT

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.


    [junit] Testcase: testInternationalURI took 0.003 sec
     [junit]     FAILED
     [junit] expected 0xf6 (\u00f6), but got 5c '\' expected:<246> but 
     [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:
For additional commands, e-mail:

View raw message