Commenting on the purpose of a file is reasonable, as it explaining why a piece of code works the way it does e.g. if an external constraint is in play. But explaining how in code comments is redundant if the code is well written and the functions and variables are well named.
function X(Y, Z){
if(Y){
foo();
}
if(Z){
bar();
}
}
If you have tests like: X(true, false);
X(false, true);
Then your code coverage from the "line" point of view is 100%. Those two tests execute every line of code. However, the two states: X(true, true);
X(false, false);
have not been tested, and if foo() and bar() both manipulate some global state, or otherwise have side effects, then the system could still break.This is an issue with many code coverage tools. The lines themselves have been executed, but not necessarily all program states.
The advantage of unit testing modular code bases is that you don't have to test every program state, you just have to test every module state.
There is a huge difference in the feasibility of 100% code coverage if you need O(2^n) vs O(n) tests.
Even if your modules are highly coupled you should be able to mock away external dependencies and side-effects.
if (foo) { setSomeState() }
At least with tools I'm familiar with, your coverage will be 100% if you have one test with 'foo = true'.
That means that you could have odd untested behavior if not executing 'setSomeState()' leaves something important unset.... but you'd have 100% coverage.
Of course in practice, 100% state coverage is really impossible to achieve.
Anyway, that amount of comment is alright for learning purposes but for an actual lengthy code base it would be a nightmare keeping all that updated. Comments are supposed to be used just for complicated/critical code, otherwise is just noise to be maintained.
# where I found your post http://webarcs.com/?open=27311