Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
User-Agent: Microsoft-MacOutlook/14.14.0.111121
Date: Tue, 20 Nov 2012 11:08:08 +0100
Subject: Any good reason why make use of the java.io.File.getAbsoluteFile()
 API inside the unit-tests
From: Babak Vahdat <babak.vahdat@swissonline.ch>
To: "dev@camel.apache.org" <dev@camel.apache.org>
Message-ID: <CCD11518.2E32%babak.vahdat@swissonline.ch>
Thread-Topic: 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="US-ASCII"
Content-transfer-encoding: 7bit

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