At first I though it was the same but with eclemma it seems different. But I can't find anything about it.
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
migrated from stackoverflow.com May 10 '12 at 21:28
This question came from our site for professional and enthusiast programmers.
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.
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.
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...
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.