Problem understanding branch, condition, statement coverage

Hi,

I am having this dilema with reference to the clear understanding of the following terms in order to pass the industry standard ISEB certification. Any help with a small piece of code would be greately appreciated.


Branch coverage
Statement coverage
Condition coverage
Method coverage


Thanks..

Those four terms look alarmingly like insurance terms. "You're covered, until you're sick, or dead, or your house floods or burns ... then you aren't"

Google's Define: seems to work as a starting point. I've been out of college since Papa Bush was in office so those terms don't jump out of the memory banks specifically.

I think he's referring to unit testing. We don't (yet) do that here so I can't help much.

I presumed the subject was unit testing also, but the question is somewhat confusing.

A method is the smallest unit in an OOP design (a function, procedure, or subroutine would be in other designs).

The statement, branch, and condition terms baffle me unless they refer to the contents of a method or function. I don't consider them to be "unit testing" terms, however, but simple programming terms.

A good unit test will ensure that all possible branches are taken, which means exercising the unit so that enough conditions occur to guarantee that. Given that, every statement will be executed.

Again, though, I'm not sure that's the thrust of the question.

He's referring to code coverage

Here's a source of information regarding Statement and Branch Coverage.

Method coverage is a code coverage metric that measures whether a method was entered at all during execution. This seems to consider all possible execution paths.

Statement coverage seems to deal with measuring whether a block of code can be executed. if(false) printf("Hello World!"). The printf would never execute.

Couldn't find a clear explanation of Condition Coverage, but it appears to be a test to display all possible outcomes of a boolean expression.

Branch coverage seems to deal with verifying that boolean expressions can evaluate to both true and false. It seems that condition coverage can aid in this.

Remember tech291083, google is your friend.

I sat ISEB in 2006, but for the life of me I can't remember a bloody thing about them

(Heads off to dig out the folder . . . . .)

Code coverage was a semi-popular way of judging quality in software. The problem is that mechanical attempts to judge quality of software are hopeless.

This is related to 'white box' testing, where you look inside the code

Quality code is like porn, you can't define it, but you know it when you see it.

How would you handle it?? Just curious.