views:

396

answers:

5

Hello,

I have installed on my computer C++Test only with UnitTest license (only Unit Test license) as a Visual Studio 2005 plugin ( cpptest_7.2.11.35_win32_vs2005_plugin.exe ).

I have a sample similar to the following:

bool MyFunction(... parameters... )
{
    bool bRet = true;

        // do something
    if( some_condition )
    {
        // do something
        bRet = CallToAFunctionThatCanReturnBothTrueAndFalse....
    }
    else
    {
        bRet = false;
        // do something
    }

    if(bRet == false)
    {
        // do something
    }

    return bRet;
}

In my case after running the coverage tool I have the following results (for a function similar to the previously mentioned):

[LC=100 BC=100 PC=75 DC=100 SCC=100 MCDC=50 (%)]

I really don't understand why I don't have 100% coverage when it comes to PathCoverage (PC). Also if someone who has experience with C++Test Parasoft could explain the low MCDC coverage for me that would be great.

What should I do to increase coverage? as I'm out of ideas in this case. Directions to (some parts of) the documentation are welcome.

Thank you,

Iulian

+3  A: 

I can't help with the specific tool you're using, but the general idea with path coverage is that each possible path through the code should be executed.

If you draw a flowchart through the program, branching at each if/break/continue, etc. you should see which paths your tests are taking through the program. To get 100% (which isn't totally necessary, nor does it assure a perfect test) your test will have to go down every branch of the code, executing every line.

Hope that helps.

rossmcf
I know what you are saying but my guess is that C++Test does not eliminate some cases that are not possible. For example you cannot execute the "else" part without executing the last "if". Probably this case is not removed by C++Test from the list of possibilities.
Iulian Şerbănoiu
@Iulian: I think you are answering your own question in this comment.
Daniel Daranas
+1  A: 

You need at least two testcases to get 100% coverage. One where some_condition is true and one where it is not. If you have that you should get 100% coverage.

Though you should see 100% coverage as perfect. You would need 3 tests for that in this case so all combinations can be tested. Look up cyclomatic complexity to learn more about that.

tombjo
I did all the possible test cases. The line coverage (LC) and the block coverage (BC), the decision coverage (DC) simple condition converage(SCC) is 100% as you can see.The only problem is Path Coverage (PC) and MCDC (Modified Condition, Decision Coverage) are not 100% though I tested all the cases. This is why I think that this is somehow a sort of bug of C++Test.
Iulian Şerbănoiu
@Iulian: No. I think it's what you said in the other comment.
Daniel Daranas
+2  A: 

This is a good reference on the various types of code coverage: http://www.bullseye.com/coverage.html.

MCDC: To improve MCDC coverage you'll need to look at some_condition. Assuming it's a complex boolean expression, you'll need to look at whether you're exercising the necessary combinations of values. Specifically, each boolean sub-expression needs to be exercised true and false.

Path: One of the things mentioned in the link above as being a disadvantage of path coverage is that many paths are impossible to exercise. That may be the case with your example.

Pete TerMaat
I think this http://www.bullseye.com/coverage.html#basic_path is a good example about what PathCoverage (PC) means. This means that indeed the C++Test doesn't eliminate the "impossible" cases.
Iulian Şerbănoiu
+1  A: 

There are four hypothetical paths through that function. Each if-clause doubles the number of paths. Each if-statement is a branch where you can go two different ways. So whenever your tool encounters an "if", it assumes the code can either take the "true" branch or the "false" branch. However, this is not always possible. Consider:

bool x = true;
if (x) {
    do_something();
}

The "false" branch of the if-statement is unreachable. This is an obvious example, but when you factor in several if-statements it becomes increasingly difficult to see whether a path is possible or not.

There are only three possible paths in your code. The path that takes the "false" branch in the first if statement and the "true" branch in the second is unreachable.

Your tool is not smart enough to realize that.

That being said, even if the tool is perfect, obtaining 100 % path coverage is probably unlikely in a real application. However, very low path coverage is a sure sign that your method has too high cyclomatic complexity.

waxwing
If there are four theoretical paths through that function, then your theory is wrong. What theorem prover are you using?
Pete Kirkham
The above is an assumption. I am not familiar with C++Test, I am sorry to say.
waxwing
@Pete Kirkham There are 4 theoretical paths (in my sample function), and only 3 of them are possible. See the link given by Pete TerMaat for more details about coverage.
Iulian Şerbănoiu
markh44
Any hypothesis that asserts that the execution of both the "bRet = false;" line is followed by "(bRet == false)" evaluating to false reduces to the assertion that false != false and therefore invalid. What you appear to be trying to say is that there are four hypothetical paths, of which three are possible, and the tool doesn't have a good enough model of software theory to prune the impossible hypothetical cases. The fourth path isn't theoretically possible but not possible in practice - it's not possible in theory either.
Pete Kirkham
Yes, "hypothetical" is the word I am looking for. I hope you don't mind that I correct my answer based on your comment. :)
waxwing
A: 

Personally, I think it's bad form to start ANY function with

bool retCode = true;

You're making an explicit assumption that it'll succeed by default, and then fail under certain conditions.

Programmers coming after you will not make this same assumption.

Fail fast, fail early.

And as others have said, if you want to test failure cases, you have to code tests that fail.

Chris Kaminski
Not related to this question but it's a good point of view. BTW I'm just unit testing existing code, which cannot be modified while tests are being written.
Iulian Şerbănoiu