Re: [PATCH 0/4] Coverage support revisited

[Thomas Rast <trast@inf.ethz.ch>]

Jens Lehmann <Jens.Lehmann@web.de> writes:

> Am 13.05.2013 23:27, schrieb Thomas Rast:
>> Jens asked me at git-merge if coverage support was still available.
>> Turns out it is, but there were some weirdnesses.  So this should fix
>> them.  It is reaaaally slow as you still have to run the tests one by
>> one; despite claims in the wild that it is multiprocess- safe but
>> thread-unsafe, I am in fact observing the opposite behavior pretty
>> clearly.  (As before, it switches to sequential tests automatically,
>> so you have to edit the Makefile if you want to try with parallel
>> tests.)
>
> Thx! That might explain why the coverage run I tried today didn't
> work (I saw bogus test failures).

Indeed it does.  I should have mentioned it in the cover letter; it's
fixed by this series but if you set DEFAULT_TEST_TARGET=prove like
everyone else, it ignored the (existing) force-to-sequential rule.

>> unpack-trees.c: verify_clean_submodule
>
> This is the one I was after. While discussing my recursive update
> code with Peff on Saturday we wondered if that function would ever
> be called. I'll check if the tests are missing some relevant cases,
> if that function can be removed or some refactoring is necessary.
>
> Hmm, while function coverage is already extremely useful me thinks
> lcov support would be really nice. We'd have line and branch coverage,
> which help me a lot in finding dead code and missing tests at $DAYJOB
> ... will look into that when I have the recursive update ready.

Actually if you run it, it generates submodule.c.gcov as an intermediate
step to the uncovered-functions list.  Of course you can also use any
other tool that can read gcov; the results are cleaned before the run,
not after, so they will remain in place.

Originally I hacked together an uncovered-functions list because that
list was so long that looking at things in even more detail seemed
extremely pointless.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch