taskLiberty Eiffel - Tasks: task #12783, coverage


You are not allowed to post comments on this tracker with your current authentification level.

task #12783: coverage

Submitted by:  Cyril Adrian <cadrian>
Submitted on:  Sat Aug 24 10:52:45 2013  
Should Start On: Fri Aug 23 22:00:00 2013Should be Finished on: Fri Aug 23 22:00:00 2013
Category: SmartEiffelPriority: 5 - Normal
Status: NonePercent Complete: 0%
Assigned to: NoneOpen/Closed: Open
Fixed Release: NonePlanned Release: None
Effort: 0.00

Mon Aug 26 17:00:20 2013, comment #5:

yes, you are right. C0 and C1 are included in MC/DC, so it may be enough to do analysis in the reports. Actually MC/DC is a hard goal, which may be "too much" for some project.

Raphael Mack <ramack>
Project Administrator
Mon Aug 26 14:43:28 2013, comment #4:

OK, after thinking about it I agree with you. We will need to work a bit to distinguish normal statements to those called in a contract checking context (I think it is quite feasible).

About C0, C1, MC/DC: isn't MC/DC enough to implement? Others are degenerate cases aren't they?

MC/DC is what I thought to implement: I think it will follow quite closely the sedb checkpoints (pseudo-instructions inserted in -sedb mode, see the SEDB class).

Cyril Adrian <cadrian>
Project Administrator
Sun Aug 25 12:44:01 2013, comment #3:

What do you think is interesting at the question whether a statement is covered in a contract? For me a use of a statement in a contract is just for the description/definition and validation of another feature. I think there are two aspects in covering a statement in a test: 1. it is covered, because the functionality around the statement is tested 2. it is covered, because it was necessary to setup the test case i. e. just covered "accidental". For the measure "coverage" I consider mainly the first interesting, while statements executed during contract checking contribute to the second class.

about C0, C1 and MC/DC: there are different interpretations and many other definitions. Mine - and what I consider interesting - is:

C0: every statement (in syntactical sense of the compiler) is executed
C1: every branch is taken, even if the branch is not explicitly visible in the code i. e. also the non-written else branch of an if
MC/DC: C1 but with every part of a compound condition taken alone: i. e. if(a && b) the if has to be not taken due a and not taken due to a and once not token due to b.

Raphael Mack <ramack>
Project Administrator
Sun Aug 25 12:10:53 2013, comment #2:

OTOH, contract coverage may be an interesting measure too.

I am not well versed in coverage theory, could you explain what are C0, C1, MC/DC?

Cyril Adrian <cadrian>
Project Administrator
Sat Aug 24 11:28:41 2013, comment #1:

Very good idea! We should think about the question whether a "statement" should be considered as covered in case it is covered only during contract checking. I consider the coverage without contract checking much more interesting. - Maybe, this could be reached by just selecting the right compilation mode...

"statement" should be configurable to mean the coverage criteria (C0, C1, MC/DC should be enough for the beginning.)

Raphael Mack <ramack>
Project Administrator
Sat Aug 24 10:52:45 2013, original submission:

Enhance c2c, eiffeltest, pretty, and ET with a code coverage option.

May also need a specific tool for consolidation.

Cyril Adrian <cadrian>
Project Administrator


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by ramack (Posted a comment)
  • -unavailable- added by cadrian (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    No Changes Have Been Made to This Item

    Back to the top

    Powered by Savane 3.1-cleanup