db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Katherine Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Code coverage for client.net package
Date Mon, 18 Jun 2012 18:10:51 GMT
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:
These are the books that describe the protocol flow between server and 

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:

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 

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?



View raw message