db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: Code coverage for client.net package
Date Wed, 06 Jun 2012 11:10:08 GMT
Mohamed Nufail <nufail56@gmail.com> writes:

> Hi,
> Next I will focus on NetConnectionReply, NetPackageReply and
> NetResultSetReply classes of the client.net package which have low
> code coverage. I will look into these classes to get a better
> understanding of them. I would like to know any suggestions regarding
> this.

Hi Nufail,

I think a good first step would be to go through the methods that have
0% coverage and see if they have any callers at all ("find usages" in
your favourite IDE should give a good indication). If they are not
called anywhere in the code, the methods could probably just be removed.

When the obviously dead code is removed, the next step would be to find
out how to exercise the remaining code that's not covered. In these
classes, it will require a lot of detective work and guessing, I think,
as it isn't always easy to see which top-level calls will cause this
low-level code to run.

One strategy may be to pick one piece of code that lacks coverage, for
example this if-statement in NetResultSetReply.parseCNTQRYreply()

172	        if (peekCP == CodePoint.ENDQRYRM) {
173	            found = true;
174	            parseEndQuery(resultSetI);
175	            peekCP = peekCodePoint();
176	        }

and find the corresponding code on the server which sends that kind of
data to the client. DRDAConnThread is the server class that's
responsible for sending data to the client, and a search for the string
ENDQRYRM in that class will lead you to this code:

759	      writeQRYDTA(stmt);
760	      if (stmt.rsIsClosed())
761	      {
762	              writeENDQRYRM(CodePoint.SVRCOD_WARNING);
763	              writeNullSQLCARDobject();
764	      }

The coverage report says that the writeENDQRYRM() method is never
called, so the question that needs to be answered, is how can
rsIsClosed() return true here. If it's at all possible.

However, it looks like a lot of the code is handling errors, many of
them protocol errors (which would only happen if there's a bug in the
server or the client) or very unlikely errors (like
NetResultSetReply.parseCloseError() which is only called if the server
experienced an error in ResultSet.close()). It's very hard to test this
code, and it might even require changes on the server to force it to
generate errors while testing.

It might be easier to start with the classes that implement the java.sql
interfaces in the client.am package, as most of their methods could be
called directly from the test. I see for example that classes like
LogicalPreparedStatement and LogicalCallableStatement have very little

Knut Anders

View raw message