db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Pendleton <bpendleton.de...@gmail.com>
Subject Re: Code coverage for client.net package
Date Sun, 17 Jun 2012 17:07:51 GMT
> 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)
> 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

Hello Nufail,

I think that these methods are going to be challenging to exercise, since
they may only arise due to implementation errors in either the client or
the server.

We have a special test suite that we have used in the past to force the
execution of code paths such as these. You can find that test suite here:


and its test data is located here:


As a first step, you could try running the ProtocolTest test suite with
code coverage enabled, just to confirm that it doesn't currently exercise
these particular methods in NetConnectionReply.

To run just that one test, you can do:

ant -Dderby.junit.testclass=org.apache.derbyTesting.functionTests.tests.derbynet.ProtocolTest

(Or use the emma-single target, of course, to get coverage information)

Then, the next step, is to see if we can add some additional tests into the
ProtocolTest suite to add this coverage.

We may find that we have to enhance ProtocolTest.java, in addition to adding
more tests in protocol.tests. For example, to specify a code point, the test
suite runs the 'startDdm' statement in protocol.tests, which causes ProtocolTest
to run the getCP() and decodeCP() methods, which appear to currently be coded
to refuse the specification of an unknown code point, so we may have to start
by allowing the tests to specify an unknown code point; then you can add a test
which specifies that unknown code point.

Again, I encourage you to open separate JIRA issues for each of these various
tasks, so that you can record your investigations into the various methods,
and (eventually) record test patches that you develop.



View raw message