db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <kristian.waa...@oracle.com>
Subject Re: Code Coverage
Date Sun, 10 Jun 2012 09:13:08 GMT
On 10.06.2012 05:36, siddharth srivastava wrote:
> Hi
>
> I went through the entire package org.apache.derby.iapi.jdbc.
> The emma code coverage report, doesn't seem to have EngineStatement
> and the related classes, AuthenticationService but as I see they are
> already used in the unit tests. I am just wondering what may be the
> reason behind it.

Hi Siddharth,

Isn't EngineStatement an interface?
Not sure how the various code coverage tools cover interfaces, maybe 
they only record coverage for the implementing classes?
(for interfaces they could of course only tell which methods have been 
invoked or not, in addition to recording coverage for static blocks 
and/or field initializations)


Regards,
-- 
Kristian

>
> It seems that this package owes most of its code coverage results to
> other packages.
>
> For example:
> DerbyServerStarter mostly owes its code coverage to
> NetworkServerControl and NetworkServerControlImpl which are tested in
> NetworkServerTestSetup[1]
> Also I noticed that the code involving security manager are not
> covered by emma results (DERBY-5514) so the method and block coverage
> results are not the true indicators for this case.
>
> I have a doubt over coverage of BrokeredStatement. I wasn't able to
> find exactly how BrokeredStatement has been tested though it seems
> that the code coverage results come from XAConnection and
> EmbedStatement.
>
>
> [1]  http://dbtg.foundry.sun.com/derby/test/coverage/_files/6.html
> [2]: http://dbtg.foundry.sun.com/derby/test/coverage/_files/1f.html
>
>
> Thanks
>
> On 18 May 2012 20:10, Bryan Pendleton<bpendleton.derby@gmail.com>  wrote:
>>> I have chosen the following packages to work on during GSoC 2012:
>>>
>>> 1) org.apache.derby.iapi.jdbc
>>> 2) org.apache.derby.impl.io<http://org.apache.derby.impl.io>
>>>
>>
>> These seem like excellent choices. They are important packages, and
>> we would like to be extremely thorough in our testing of these packages.
>>
>> I think it would be useful to look inside the packages in more detail.
>>
>> Within the packages named above, which particular classes are
>> currently the least-covered by our existing tests? (Both in terms
>> of percentage of coverage, and in terms of the amount of the un-covered
>> code.)
>>
>> thanks,
>>
>> bryan
>>
>>
>
>
>


Mime
View raw message