Hi,
I looked into some methods with low coverage to get an idea as to how to
invoke them through a test.
parseSQLDCGRP (Sqlca [], int): int in NetConnectionReply
This seems to be called through parseSQLDIAGGRP(Sqlca[] rowsetSqlca). But
code coverage shows that it returns after executing following if statement
and it never reaches code below that.
2757 if (readFastUnsignedByte() == CodePoint.NULLDATA) {2758
return 0; 2759 }
So this would be invoked if we don't have NULLDATA code point. How is it
possible?
parseCMDNSPRM (): void in NetConnectionReply
This would be invoked by parseCommonError(int) in NetConnectionReply or
parseFetchError(ResultSetCallbackInterface) in NetResultSetReply when we
have a CMDNSPRM code point. This could happen when DRDAConnThread.java
calls codePointNotSupported(int codePoint) method which is the default case
for the switch(codePoint) statement in processCommands() method in
DRDAConnThread.
So when can we have a code point which is different to the code points
checked in processCommands()?
Any idea regarding these tests or how to proceed with improving the
coverage would be helpful.
thanks,
Nufail.
On Wed, Jun 13, 2012 at 3:27 AM, Dag H. Wanvik <dag.wan...@oracle.com>wrote:
> Bryan Pendleton <bpendleton.de...@gmail.com> writes:
>
> >> This looks like a great collection of methods to focus on.
> >>
> >> Actually what I meant to say was that these methods are not being
> >> called in anywhere. Code inspection from my IDE revealed that
> >> these methods are unused. So it might be possible to remove them.
> >
> > Even better!
> >
> > Although it is possible to do tricky things like invoking methods
> > via reflection, in general the Derby codebase doesn't do that
> > (there are some important exceptions, but...).
> >
> > So if your IDE believes that these methods aren't being called,
> > I agree that it seems like we should be able to remove them.
>
> I usually do a textual search as well to avoid missing those few that
> are called via reflection. Note that on the server side it is not enough
> to search the Java files, some classes are referenced only via
> .properties files (module implementations). So I usually search
> everything under "java", or, if I am certain it's not in the
> "java/shared" folder, just in "java/engine". But there are even
> exceptions to that: some classes are only used by tests (scaffolding),
> so sometime search all inside all of "java" may be necessary, some stuff
> in "java/build" is only called from Ant build.xml scripts etc.. YMMV.
>
> I think the client side is easier, though: reflection is probably the
> only pit one can fall into there, so textual search in "java/shared" and
> "java/client" should suffice.
>
> Dag
>
>
>
>
> >
> > Let's proceed on the assumption that we'll try to remove these
> > unused and un-called methods, unless we can find some evidence
> > that shows a reason to retain them.
> >
> > thanks,
> >
> > bryan
>
--
Mohamed Nufail
Undergraduate,
Department of Computer Science & Engineering,
University of Moratuwa.
Blog: http://www.nufailm.blogspot.com/
