3 ms·
> Give me one project and I'll send you a test suite that "tests" 100% of executable lines. I don’t think you can do that with every project. For example, a fu
by Someone 4y ago
> Give me one project and I'll send you a test suite that "tests" 100% of executable lines.
I don’t think you can do that with every project. For example, a function f may do:
if (p == null) {
abort();
}
If all callers also do that test, there’s no way to hit that abort() line in the program. Your test suite may not be able to hit it either. Maybe f is a private function, or that test occurs on one of its intermediate values, or f accidentally has two identical tests:
if (p == null) {
abort(“p is null”);
}
if (p == null) { // copy-paste bug
abort(“q is null”);
}
if (r == null) {
abort(“r is null”);
}
Even if it is possible to hit that line, finding a path through the code that passes in a null value can be extremely hard.
As a simple contrived counterexample, try getting 100% coverage on a function that does if(secure_hash(foo) == 0) bar();
- phoe-krk 4y ago> Your test suite may not be able to hit it either. Minor nitpick, process terminations are unit-testable in general; see e.g. https://github.com/google/googletest/blob/main/docs/advanced.md#death-tests https://github.com/google/googletest/blob/main/docs/advanced...
- garaetjjte 4y agoThey don't count assertions in testing coverage: https://www.sqlite.org/testing.html#coverage_testing_of_defensive_code https://www.sqlite.org/testing.html#coverage_testing_of_defe...
- jonhohle 4y agoWhat is fair in testing and what is being tested? If I can stub `secure_hash` and `bar`, that’s a pretty easy test to write. Assuming the symbols are visible at test time, stubbing those is relatively straight forward in C, Java, Bash, and Ruby, JavaScript, etc. Even in the above examples, a linter should point out that the second `p == null` is inaccessible. I’m very pro test coverage, but static analysis shouldn’t be thrown out just because unit tests are available.