On 6/17/2012 1:37 AM, Mohamed Nufail wrote:
Hi,
I looked into some methods with low coverage to get an idea as to how
to invoke them through a test.
First in case you have not been introduced to the amazing literary
masterpiece and valuable sleep aid of the three volume 2000+ page DRDA
standard, I wanted to point you to that:
https://collaboration.opengroup.org/dbiop/?gpid=453
These are the books that describe the protocol flow between server and
client
I think chapter 4 of the DRDA manual (volume 1) is worth skimming
especially trying to understand some of the sample flows as in Figure
4-2, 4-21, 4-27, and correlating the commands to the DDM manual and
understanding how to look up specific commands in there. Note Derby does
not do any of the binding described at length in this chapter.
We also have a couple of good protocol related pages that Bryan put on
our wiki:
http://wiki.apache.org/db-derby/ProtocolDebuggingTips
http://wiki.apache.org/db-derby/DssProtocolErrors
After doing some reading, try in ij connecting to network server with
the tracefile attribute, e.g. start network server and connect with:
connect 'jdbc:derby://localhost:1527/wobmat;create=true;traceFile=trace.out'
and then do a simple create table, insert and select and look at the
trace file. See if you can follow the protocol in the trace file as it
relates to the JDBC executed.
This will give a good protocol primer to understand how to track down
ways to cover code and what is important to cover.
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?
So since the client is parsing what the server is writing, you would
want to look for the corresponding writeSQLDCGRP method in
DRDAConnThread. Is that covered and is it possible that the server
would ever write anything more than NULLDATA at this point? If not, is
it worth keeping the client code beyond this statement?
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()?
parseCMDNSPRM() this is where the client would parse a response from
the server that the client sent invalid protocol, so we don't expect
that we would ever have to go through that code, yet it makes sense for
both the server to handle receiving an invalid command and client to
parse the server's response. We don't have a good mechanism for
covering these types of negative protocol tests for the client.
We actually have a mechanism for covering these types of negative cases
for the server which is the protocol tests. They are invoked in the test
org.apache.DerbyTesting.functionTests.tests.derbynet.ProtocolTest but
the actual protocol being tested is in a file called protocol.tests
which is a sort of protocol script and simulated client. You can see
the checkError lines check for various protocol errors. (protocol.tests
is actually worth looking at as part of your DRDA study.) Using this
mechanism, one could cover the server codePointNotSupported method, but
obviously it wouldn't help with the client.
I suppose some similar test framework.could be written to throw
unexpected protocol at the client to exercise some of the client code
to detect a misbehaved server but I don't think it is worth it. In
addition this particular case is geared to detecting the client gives a
proper response to to the server's proper response to the client
misbehaving, so I think it is just one of those cases that ok to leave
uncovered.
I would prefer to see you focus on code paths for positive cases than
extremely remote negative protocol errors.
So if looking at NetConnectionReply, I would say focus first on methods
that are not covered at all and do not sound protocol error related for
example, in that file I see parseRDBATHRM which I would think we would
cover for an authentication failure and something called
verifyConnectReply(). Is that called anywhere and what should it do? You
might want to look at a higher level am.Connection and net.Connection.
What's not covered there?
HTH
Kathey
