Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of willem.jiang@gmail.com
 designates 209.85.220.45 as permitted sender)
Date: Wed, 21 Nov 2012 09:07:26 +0800
From: Willem jiang <willem.jiang@gmail.com>
To: dev@camel.apache.org
Message-ID: <F555FD0CC85345D6B2DD8A27E4EFC18C@gmail.com>
In-Reply-To: <CCD11518.2E32%babak.vahdat@swissonline.ch>
References: <CCD11518.2E32%babak.vahdat@swissonline.ch>
Subject: Re: Any good reason why make use of the
 java.io.File.getAbsoluteFile() API inside the unit-tests
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

+1 to remove that to save us some testing time :)

-- 
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
          http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang 
Weibo: willemjiang


On Tuesday, November 20, 2012 at 6:08 PM, Babak Vahdat wrote:

> Hi
> 
> Looking at unit-tests all over the places we've got *tons* of this API
> call, like:
> 
> assertTrue("File should not have been deleted", new
> File("target/files/report.txt").getAbsoluteFile().exists());
> 
> Which could simply be modified to
> 
> assertTrue("File should not have been deleted", new
> File("target/files/report.txt").exists());
> 
> 
> The only benefit I see is that using this API you would see the absolute
> file/directory path at the stacktraces when the asserts would fail, like:
> 
> 
> File file = new File("target/issue/test.txt").getAbsoluteFile()
> 
> assertTrue("File " + file + " should exist", file.exists());
> 
> Note that by the example above we instantiate 2 file handles, one of which
> we don't reference at all, which's the "new File("target/issue/test.txt")"
> object.
> 
> If there's no other advantages I'm missing here I would suggest to remove
> all such these calls, as it consumes both the CPU-time as well makes I/O,
> not sure though how expensive really these (native OS) calls would be, but
> for sure they're not for free.
> 
> Thoughts?
> 
> Babak