db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mohamed Nufail <nufai...@gmail.com>
Subject Re: Code coverage for client.net package
Date Mon, 18 Jun 2012 13:47:39 GMT
Hi,

Thank you for the guidance. I will try running ProtocolTest and open JIRA
issues and continue with your suggestions.

Thanks,
Nufail.

On Sun, Jun 17, 2012 at 10:37 PM, Bryan Pendleton <
bpendleton.derby@gmail.com> wrote:

> 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
>



-- 

Mohamed Nufail
Undergraduate,
Department of Computer Science & Engineering,
University of Moratuwa.
Blog: http://www.nufailm.blogspot.com/

Mime
View raw message