Jens Lehmann <jens.lehm...@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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
