Sonar

Branch/Condition Coverage Display Improvement

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 3.1, 3.1.1
  • Fix Version/s: None
  • Component/s: Code Coverage
  • Labels:
    None
  • Number of attachments :
    0

Description

In sonar 3.1, branch coverage is diplay like the following 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.

A good way of presenting this would be,

T/F for the branch in one column, and then in another column for each condition also T/F description.

Merging this with line coverage needs to be figured out.

Thanks..

Check discussion in: http://sonar.15.n6.nabble.com/Metric-for-method-level-code-coverage-td5001317.html

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Evgeny Mandrikov added a comment -

I'm not sure that some of existing coverage tools can provide such information. Typically maximal granularity - is line.

Show
Evgeny Mandrikov added a comment - I'm not sure that some of existing coverage tools can provide such information. Typically maximal granularity - is line.
Hide
Permalink
Jorge Costa added a comment - - edited

Quite disappointing knowing this, we are using Bullseye coverage and its a given. This issue was raised mostly taking this into consideration.

But i thought clover had in the reports a true count and false count at least? In this case at least the branch can be evaluated True or False. As for the conditions, than thats a different story

Show
Jorge Costa added a comment - - edited Quite disappointing knowing this, we are using Bullseye coverage and its a given. This issue was raised mostly taking this into consideration. But i thought clover had in the reports a true count and false count at least? In this case at least the branch can be evaluated True or False. As for the conditions, than thats a different story
Hide
Permalink
Evgeny Mandrikov added a comment -

Correct me, if I'm wrong, but Bullseye is a code coverage analyzer for C++ and C. And I talked about coverage tools for Java, which based on bytecode analysis. Clover isn't in this category, because it works on source code level.

Show
Evgeny Mandrikov added a comment - Correct me, if I'm wrong, but Bullseye is a code coverage analyzer for C++ and C. And I talked about coverage tools for Java, which based on bytecode analysis. Clover isn't in this category, because it works on source code level.
Hide
Permalink
Jorge Costa added a comment -

Yes bullseye is for c/c++. But i was trying to be as generic as possible, since coverage is a concept independent of the language (like Sonar).

In my case i was implementing a parser for the cxx plugin and me and other developers in my company commented on this.

For clover ive only seen the report, was not aware how the coverage is calculated.

Show
Jorge Costa added a comment - Yes bullseye is for c/c++. But i was trying to be as generic as possible, since coverage is a concept independent of the language (like Sonar). In my case i was implementing a parser for the cxx plugin and me and other developers in my company commented on this. For clover ive only seen the report, was not aware how the coverage is calculated.
Hide
Permalink
Waleri Enns added a comment -

Displaying such information could be of value. And if the actual coverage metrics should be extended I would probably vote for MC/DC (Modified Condifition / Decision Coverage). Its has a high bug exposure rate and can be achieved with a reasonable effort. Its not uncommon to require it for safety critical code ((Aero)space and AFAIR some of medical applications (at least here in Germany)).

Show
Waleri Enns added a comment - Displaying such information could be of value. And if the actual coverage metrics should be extended I would probably vote for MC/DC (Modified Condifition / Decision Coverage). Its has a high bug exposure rate and can be achieved with a reasonable effort. Its not uncommon to require it for safety critical code ((Aero)space and AFAIR some of medical applications (at least here in Germany)).

People

  • Assignee:
    Unassigned
    Reporter:
    Jorge Costa
Vote (0)
Watch (3)

Dates

  • Created:
    Updated: