You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Babak Vahdat <ba...@swissonline.ch> on 2012/11/20 11:08:08 UTC
Any good reason why make use of the java.io.File.getAbsoluteFile()
API inside the unit-tests
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
Re: Any good reason why make use of the java.io.File.getAbsoluteFile() API inside the unit-tests
Posted by Daniel Kulp <dk...@apache.org>.
On Nov 21, 2012, at 1:45 AM, Babak Vahdat <ba...@swissonline.ch> wrote:
> I was *not* looking for any +1 but only wanted to *make sure* that there's
> *no* good reason I'm missing here why there're *tons* of this call. So that
> I though I should better ask other experienced riders before I start
> removing (almost) all of those 226 calls!
The only thing I can think of (and we do need this in CXF) is if you need a full URL/URI for the file for some reason. In CXF this is usually to get the complete URL to a base WSDL so all the imports/includes and binding files and such will work. This likely doesn't affect 95% (or higher) of the 226 calls you mentioned.
Dan
>
> ~/dev/workspace/camel>find . -name *Test.java -exec grep "getAbsoluteFile()"
> {} \; | wc
> 226 1034 15850
>
> Babak
>
>
> hadrian wrote
>> Unfortunately, it won't save any testing time as this is just a teeny,
>> tiny drop in the bucket, but it's a bit ugly.
>>
>> Babak, you don't need a bunch of +1s, just go ahead and fix it :).
>>
>> Thanks,
>> Hadrian
>>
>> On 11/20/2012 08:07 PM, Willem jiang wrote:
>>> +1 to remove that to save us some testing time :)
>>>
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Any-good-reason-why-make-use-of-the-java-io-File-getAbsoluteFile-API-inside-the-unit-tests-tp5722995p5723042.html
> Sent from the Camel Development mailing list archive at Nabble.com.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Any good reason why make use of the
java.io.File.getAbsoluteFile() API inside the unit-tests
Posted by Babak Vahdat <ba...@swissonline.ch>.
Hi Hadrian,
I was *not* looking for any +1 but only wanted to *make sure* that there's
*no* good reason I'm missing here why there're *tons* of this call. So that
I though I should better ask other experienced riders before I start
removing (almost) all of those 226 calls!
~/dev/workspace/camel>find . -name *Test.java -exec grep "getAbsoluteFile()"
{} \; | wc
226 1034 15850
Babak
hadrian wrote
> Unfortunately, it won't save any testing time as this is just a teeny,
> tiny drop in the bucket, but it's a bit ugly.
>
> Babak, you don't need a bunch of +1s, just go ahead and fix it :).
>
> Thanks,
> Hadrian
>
> On 11/20/2012 08:07 PM, Willem jiang wrote:
>> +1 to remove that to save us some testing time :)
>>
--
View this message in context: http://camel.465427.n5.nabble.com/Any-good-reason-why-make-use-of-the-java-io-File-getAbsoluteFile-API-inside-the-unit-tests-tp5722995p5723042.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Any good reason why make use of the java.io.File.getAbsoluteFile()
API inside the unit-tests
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Unfortunately, it won't save any testing time as this is just a teeny,
tiny drop in the bucket, but it's a bit ugly.
Babak, you don't need a bunch of +1s, just go ahead and fix it :).
Thanks,
Hadrian
On 11/20/2012 08:07 PM, Willem jiang wrote:
> +1 to remove that to save us some testing time :)
>
Re: Any good reason why make use of the
java.io.File.getAbsoluteFile() API inside the unit-tests
Posted by Willem jiang <wi...@gmail.com>.
+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
Re: Any good reason why make use of the java.io.File.getAbsoluteFile()
API inside the unit-tests
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I suggest to test this on Windows as well. And do a fix in a single
file to ensure it works across the CI servers etc.
On Tue, Nov 20, 2012 at 11:08 AM, Babak Vahdat
<ba...@swissonline.ch> 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
>
>
>
>
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: Any good reason why make use of the java.io.File.getAbsoluteFile()
API inside the unit-tests
Posted by Christian Müller <ch...@gmail.com>.
IMO, there is no need for this additional API call.
+1 for removing it.
Best,
Christian
Sent from a mobile device
Am 20.11.2012 19:57 schrieb "Babak Vahdat" <ba...@swissonline.ch>:
>
>
> Am 20.11.12 11:08 schrieb "Babak Vahdat" unter
> <ba...@swissonline.ch>:
>
> >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());
>
> And here one concrete example of this:
>
> https://svn.apache.org/repos/asf/camel/trunk/camel-core/src/test/java/org/a
> pache/camel/builder/xml/XsltBuilderTest.java
>
> There're totally 8 calls to this method! Of course removing all of those
> calls has no effect on the test results, as they all would still pass.
>
> Babak
>
> >
> >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
> >
> >
> >
> >
>
>
>
Re: Any good reason why make use of the
java.io.File.getAbsoluteFile() API inside the unit-tests
Posted by Babak Vahdat <ba...@swissonline.ch>.
Am 20.11.12 11:08 schrieb "Babak Vahdat" unter
<ba...@swissonline.ch>:
>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());
And here one concrete example of this:
https://svn.apache.org/repos/asf/camel/trunk/camel-core/src/test/java/org/a
pache/camel/builder/xml/XsltBuilderTest.java
There're totally 8 calls to this method! Of course removing all of those
calls has no effect on the test results, as they all would still pass.
Babak
>
>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
>
>
>
>