In the code coverage analysis in VSTS, we provide two types of stats: block coverage and line coverage.

I just wanted to clarify a few points.  First, when we say block coverage, we are referring to basic blocks in the binary being tested, *not* in the source.  A basic block is segment of machine code with a single control flow entry and a single exit.  Also, call statements (being control flow) do count as the end of a basic block.  

The reason I mention this is that people often get confused by the block totals in their methods.  Take this simple example and count the blocks you would expect to see. 

int _tmain() {
1:    MyClass c;
2:    int i = 3;
3:    if (i){
4:       i = c.foo();
5:    }
6:    return i;
}

Many would probably guess 3: all the stuff up to the branch in line 3, the if body, and the return statement.  However, there are actually two blocks in line 4 (the call to foo ends the first block, the second is the assignment to i of its return value).  Now a really sharp programmer would notice that there are potentially 2 more!  That innocuous looking line 1 is actually a method call to the constructor to MyClass.  And finally, there's (potentially) a call to MyClass's destructor when it goes out of scope.

The moral of this story is that you shouldn't be too concerned if you can't exactly identify where all the blocks are.  When you turn the optimizer on your binary, block counts are fairly unpredictable.  Don't worry though, the source line coloring will almost always lead you to the parts of the code that you need to worry about targeting to get your coverage stats up.

I'll address line coverage frequently asked questions in my next post.