Hi,
I am working on adding path coverage support to gcc/gcov and need to
develop a good testing strategy.
So far I can reasonably well report on the uncovered path as such:
paths covered 6 of 17
path not covered: 2 8 3 4
path not covered: 2 8 3 5 6
path not covered: 2 8 3 5 7 10
...
where the numbers are the basic blocks of the CFG, which can be seen in
the source listing with gcov -a, e.g.:
#####: 6: while (low <= high)
%%%%%: 6-block 2
%%%%%: 6-block 8
Some natural test would be to by hand determine the paths taken and
compare with the gcov output, like lines/branches/conditions are tested
today. Unlike the other coverages in gcov, paths work more like function
summaries and cannot be reasonably shown in the source listing, but the
basic block listing actually works quite alright.
The problem is testing. If gcc would re-number the basic blocks then
tests comparing hard-coded test paths would break, even though the path
coverage itself would be just fine (and presumably the change to the
basic block indices), which would add an unreasonable maintenance
burden. If anything, it feels very fragile to write tests against the
basic block indices.
On the other hand, if it can be expected that the same code should
always yield the same CFG, the same BBs, and the same BB indices then I
would happily test against them. I suppose this makes the basic blocks
basically a public interface, which granted feels odd.
If you have any good idea on how to test paths in a robust way please
let me know.
Thanks,
Jørgen
