Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

At first I though it was the same but with eclemma it seems different. But I can't find anything about it.

share|improve this question

migrated from stackoverflow.com May 10 '12 at 21:28

This question came from our site for professional and enthusiast programmers.

    
I don't who downvoted this, but the question seems perfectly reasonable. What a nice way to treat a newbie. +1 to counteract. –  Ira Baxter May 10 '12 at 15:17
add comment

4 Answers

up vote 1 down vote accepted

Test coverage and code coverage as generic terms can mean a broad variety of different measures of what has been covered: lines of code, subconditions of boolean expressions, accesses to data, calls to API functions, ...

In the common vernacular, and for almost all the tools you can get, "test coverage" and "code coverage" tell you what code executed by whatever testing process you use (whether that is unit test, functional test, informal test, interactive test, ...).

The only widely used variation is MC/DC (test/code) coverage, which tells you which of the boolean subconditions in a logical expression have been exercised in a way that controls the outcome of the boolean expression. Only a few tools offer this.

I'm sure eclemma provides test/code coverage of the standard type. Whether it provides anything else... I don't know.

share|improve this answer
add comment

As the above responses the definition varies. I sometimes say code coverage does not matter to me but test coverage does.

By test coverage I mean in this context that any possible behaviour of a class should be documented by tests (ie. if you look at the tests you should be able to make a safe assumption of the outputs and behaviour of any method of that class, provided any given set of inputs. Which also includes assumptions of invalid inputs.

Lines of code that do not impact behaviour are obviously undesirable, but if they exist that is usually less relevant. For me typical examples of such lines are small best practice approaches that are actually rarely used, so I might not test if I catch an exception if a file is written and I check if it exists before trying to write it. Having that sort of check often is better than not writing or testing this kind of code.

share|improve this answer
add comment

Here is how I use these terms (although I almost never actually uses these terms).

Code coverage is a measure of how much code is executed during testing.

Test coverage is a measure of how many test cases have been executed during testing.

Your mileage may vary...

share|improve this answer
add comment

Here is how I use the terms. Code coverage is a measure of how much code is executed in response to a stimulus (e.g. running a test). Test coverage is a measure of how much of the feature set was executed as a result of a test.

Others will have other definitions. When someone uses those terms, if you are not sure what they mean, ask them.

share|improve this answer
    
+1 for "Others will have other definitions." It's dangerously true. –  user867 May 11 '12 at 1:19
    
+1 for having the same definition as me! :) –  MichaelF May 11 '12 at 16:56
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.