Metric for method level code coverage

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Metric for method level code coverage

manilalpg
Hi,

As per my understanding Test related Metrics in Sonar (line_coverage, branch_coverage, coverage) indicates number lines covered or uncovered and branches covered or uncovered. Is there any metric in Sonar which gives method level code coverage?

For example:
     
   a) # no of methods are not covered
   b) # no of methods are n% covered

Thanks,
Manilal
Reply | Threaded
Open this post in threaded view
|

Re: Metric for method level code coverage

David Racodon-2
Hi Manilal,

This answer is no.
May I ask you why you'd be interested in such metrics?

Thank you

Regards,

David RACODON | SonarSource
Senior Consultant



On 25 July 2012 13:19, manilalpg <[hidden email]> wrote:
Hi,

As per my understanding Test related Metrics in Sonar (line_coverage,
branch_coverage, coverage) indicates number lines covered or uncovered and
branches covered or uncovered. Is there any metric in Sonar which gives
method level code coverage?

For example:

   a) # no of methods are not covered
   b) # no of methods are n% covered

Thanks,
Manilal



--
View this message in context: http://sonar.15.n6.nabble.com/Metric-for-method-level-code-coverage-tp5001317.html
Sent from the Sonar user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Metric for method level code coverage

manilalpg
Hi David,

The requirement from my manager is to have an indication of how many methods are covered/not covered. As we write Unit test cases against the methods/functionalities, he think that matric would give a better  coverage indication.

Thanks,
Manilal
Reply | Threaded
Open this post in threaded view
|

Re: Metric for method level code coverage

David Racodon-2
Hi Manilal,

I would challenge your boss then.
What would be a covered method? 100% coverage of this method by unit tests? 80%? 60%?

Anyway, this metric is not in our roadmap and, unfortunately for your boss, won't be.

Regards,

David RACODON | SonarSource
Senior Consultant



On 25 July 2012 17:00, manilalpg <[hidden email]> wrote:
Hi David,

The requirement from my manager is to have an indication of how many methods
are covered/not covered. As we write Unit test cases against the
methods/functionalities, he think that matric would give a better  coverage
indication.

Thanks,
Manilal



--
View this message in context: http://sonar.15.n6.nabble.com/Metric-for-method-level-code-coverage-tp5001317p5001329.html
Sent from the Sonar user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Metric for method level code coverage

Jorge Costa
Hi David,

In my workplace we also use method coverage as provided by bullseye coverage tool, and in our case we want to see what methods are called. So covered for us means called.

More important in our case is decision/condition coverage. Can i ask if there are going to be improvements in this area within sonar?

Thanks and regards.

Jorge Costa
Best Regards
Jorge Costa
Reply | Threaded
Open this post in threaded view
|

Re: Metric for method level code coverage

Freddy Mallet
Hi Jorge,

See my comment below :

In my workplace we also use method coverage as provided by bullseye coverage
tool, and in our case we want to see what methods are called. So covered for
us means called.

Coming back to question raised by David, we're not against adding a new coverage metric but for that we need to fully understand the value of this new metric and for the time being I don't see any benefit (except generating a metric already provided by bullseye) ? 
 
More important in our case is decision/condition coverage.

Out-of-the-box Sonar provides line coverage and branch coverage measures so I guess this is what you expect. 
 
Can i ask if there are going to be improvements in this area within sonar?

Yes but effort will be focused on providing for instance :
  • the aggregated coverage by unit tests and integration tests
  • the source code covered by each test
Kind regards,
Freddy


Thanks and regards.

Jorge Costa



--
View this message in context: http://sonar.15.n6.nabble.com/Metric-for-method-level-code-coverage-tp5001317p5001338.html
Sent from the Sonar user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Metric for method level code coverage

Jorge Costa
Hi Freddy,

Thanks for your reply, indeed in my case and probably in case of many bullseye users we would like to see function coverage. And the main reason is that there is no easy way of reconstructing line coverage using bullseye reports. I guess having this could potentially increase numbers of coverage tools supported by sonar with also the most accurate results you could expect.

As for coverage provided by sonar, both are excellent and provide really great value. However the improvement that i was talking relates to the new sonar 3.1 and more specifically this example:

181 1 2/4 if (parent == null || child == null) {
182     // an event without associated path information
183     return null;
184 }
185 else {
186    int index = child.getIndex();
187 1 2/2 if (index > 0) {
188    return PathFactoryImpl.getInstance().create(parent, child.getName(), index, false);
189 } else {
190    return PathFactoryImpl.getInstance().create(parent, child.getName(), false);
191 }

In the first branch we have 2 covered conditions and we know the branch as never been true, however we dont know which condition have been evaluated to true. Ok in this case both have been evaluated to true, but when having 1/4 or 3/4 in there than its impossible to know.

But this is something you could have in mind for the future. The improvements currently in the pipeline are great and welcome..

BR,

Jorge Costa

 



Best Regards
Jorge Costa
Reply | Threaded
Open this post in threaded view
|

Re: Metric for method level code coverage

Freddy Mallet
Hi Jorge,

See my comments below :

Thanks for your reply, indeed in my case and probably in case of many
bullseye users we would like to see function coverage. And the main reason
is that there is no easy way of reconstructing line coverage using bullseye
reports. I guess having this could potentially increase numbers of coverage
tools supported by sonar with also the most accurate results you could
expect.

I understand and would be tempted to ask you to create a JIRA ticket but I'm really not sure that we'll fix it one day. Anyway that will be a good way to know if there is a big expectation on this feature from the Sonar community ... so feel free to create the ticket. 

As for coverage provided by sonar, both are excellent and provide really
great value. However the improvement that i was talking relates to the new
sonar 3.1 and more specifically this example:

181     1        2/4    if (parent == null || child == null) {
182                          // an event without associated path information
183                          return null;
184                     }
185                     else {
186                         int index = child.getIndex();
187     1        2/2    if (index > 0) {
188                         return PathFactoryImpl.getInstance().create(parent,
child.getName(), index, false);
189                     } else {
190                         return PathFactoryImpl.getInstance().create(parent,
child.getName(), false);
191                     }

In the first branch we have 2 covered conditions and we know the branch as
never been true, however we dont know which condition have been evaluated to
true. Ok in this case both have been evaluated to true, but when having 1/4
or 3/4 in there than its impossible to know.

Ok, good point, you can go ahead to create the JIRA ticket 

Thanks for your feedback,
Freddy

 
But this is something you could have in mind for the future. The
improvements currently in the pipeline are great and welcome..

BR,

Jorge Costa









--
View this message in context: http://sonar.15.n6.nabble.com/Metric-for-method-level-code-coverage-tp5001317p5001353.html
Sent from the Sonar user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Metric for method level code coverage

Jorge Costa
Hi Freddy,

Jira tickets have been created:
http://jira.codehaus.org/browse/SONAR-3709 - function coverage
http://jira.codehaus.org/browse/SONAR-3710 - branch coverage

Thanks and Regards,

Jorge Costa
Best Regards
Jorge Costa