Re: [PATCH 0/4] Coverage support revisited

From: Thomas Rast <trast@inf.ethz.ch>
Date: May 14, 2013, 09:14 UTC
Message-ID: <87k3n16hyz.fsf@linux-k42r.v.cablecom.net>
In-Reply-To: <51916A2B.3060001@web.de>

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

Show 12 quoted lines

> 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.

Show 11 quoted lines

>> 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