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.
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: java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/ProtocolTest.java and its test data is located here: java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/protocol.tests 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 junit-single (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. thanks, bryan
