Re: Code coverage tool
On Feb 4, 7:23 pm, Ian Collins <ian-n...@hotmail.com> wrote:
Pete Becker wrote:
On 2008-02-04 12:39:08 -0500, Erik Wikstr=F6m <Erik-wikst...@telia.com> =
said:
On 2008-02-04 13:32, Gerhard Fiedler wrote:
On 2008-02-04 06:55:35, Ian Collins wrote:
ev wrote:
We are looking for any testing tool that is capable of
checking code coverage for C,C ++ and Java code. Or at
least for C and C++. We want to know how much
(percentage) of our code written on C/C++ is covered in
terms of function calls and line calls. We tried
Rational PureCoverage. It's excellent but has some
limitations in our case. Any idea would be greatly
appreciated.
Write the tests first, that way nothing gets written that
isn't tested.
How do you know whether every branch/condition in a
function gets executed when you run the tests that you
wrote (independently of whether you wrote them before or
after you wrote the function)?
Because you write the tests so that all branches will be
taken. If you can not do that it means you are not testing
at a low enough level.
Or you changed some code and didn't update the tests, or the
tests missed some subtle condition that the code handles.
That's why you do coverage analysis.
If you changed some code and didn't update the tests, the
tests would fail. If the tests are written first and the code
written to pass them, there will not be any conditions that
the code handles but not the tests.
Just because the code was written to pass some set of tests
doesn't mean that there aren't branches that this set of tests
doesn't test. The most blatant example was in the old days,
when operator new returned a null pointer if there was no
memory. A lot of code back then forgot to test for null, and a
lot of test suites didn't test that they handled the case
correctly either. (Note that today, it wouldn't surprise me if
a lot of code would fail if a new expression raises bad_alloc.)
Of course, a lot of program specifications don't say what the
code should do if you run out of memory either.
With regards to coverage tools:
If you have a function along the lines:
void
f( bool c1, bool c2 )
{
if ( c1 ) {
x ;
} else {
y ;
}
if ( c2 ) {
z ;
} else {
u ;
}
}
The coverage tools I analysed back then would report 100%
coverage if you called the function twice, once with
f(true, true) and once with f(false, false), for example.
Which, of course, is completely wrong. Other cases which were
missed were things like never testing the case where a loop
executed 0 times. Not to speak of exceptions. My conclusion at
the time was that they were worthless; we needed good code
review, including review of the tests.
Hopefully, the situation has improved since then.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34