Re: [PATCH 0/4] Coverage support revisited

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> Below is the coverage-untested-functions output; it seems submodule.c
> is covered, so there is nothing for Jens to do ;-)

Hehe, I kinda expected that part ;-)

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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]