db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tiago Espinha <ti...@espinhas.net>
Subject Re: Code Coverage of impl.io
Date Mon, 09 Jul 2012 09:24:16 GMT

Hash: SHA256

On 7/8/12 5:57 AM, siddharth srivastava wrote:
> Hi
> I have been looking into the package org.apache.derby.impl.io.
> I looked that it provides various implementation of StorageFactory
> class.based on classpath, jars etc.
> What looked somewhat confusing to me is how do they get invoked in
> Derby. Are they invoked implicitly ?
> I looked at a certain methods, for example,
> StorageFile newPersistentFile( String directoryName, String fileName)
> in CPStorageFactory.
> It seems that the condition if( directoryName == null ||
> directoryName.length() == 0) is always true when it is invoked.
> So while writing a test for such function I think it would be good to
> exercise the false case as well.
> Since the method with same definition is defined and used in so many
> locations(extended from StorageFactory), how to determine which
> implementation is the one defined in CPStorageFactory.
Hi Siddharth,

For this kind of stuff, if you use Eclipse (and probably other IDEs also
have it), you have the option to find all the references to a specific
class or method within your project. This will show you which classes
are explicitly invoking that specific method.

Things get less transparent when we use inheritance. For example, if you
have an abstract class with a method called foo() and two classes extend
from this class and override this method, it's impossible to know
statically (i.e. with the approach I mentioned above) which foo() gets
invoked if you use the abstract class' type and store one of the
children in this type.

This kind of thing can only be resolved dynamically or with a good eye
and a good strategy. If you see such a case, you can try to find
references to the class and see if it's extended by any other class.

As for the specific example you have, you're right. It's important to
exercise the false case as well. Using unit tests this should be
possible, since you can directly control the method's input. If it's
still impossible (and you are 100% sure or at least sure with a 5 sigma
level of significance [n.b. it's a joke :-) *]), you can suggest (and
include in your patch) the removal of the code that's never exercised.
It can happen that some code is simply dead code which should be removed.


* - http://public.web.cern.ch/public/
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


View raw message