taskLiberty Eiffel - Tasks: task #12783, coverage


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

task #12783: coverage

Submitted by:  Cyril Adrian <cadrian>
Submitted on:  Sat 24 Aug 2013 10:52:45 AM UTC
Should Start On:  Fri 23 Aug 2013 10:00:00 PM UTC Should be Finished on:  Fri 23 Aug 2013 10:00:00 PM UTC
Category:  SmartEiffel Priority:  * 5 - Normal
Status:  None Percent Complete:  0%
Assigned to:  None Open/Closed:  Open
Fixed Release:  None Planned Release:  None
Effort:  0.00
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:
       No canned response available


Mon 26 Aug 2013 05:00:20 PM UTC, 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 26 Aug 2013 02:43:28 PM UTC, 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 25 Aug 2013 12:44:01 PM UTC, 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 25 Aug 2013 12:10:53 PM UTC, 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 24 Aug 2013 11:28:41 AM UTC, 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 24 Aug 2013 10:52:45 AM UTC, 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


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.





    No changes have been made to this item

    Back to the top

    Powered by Savane 3.9