From: Thomas Rast Date: Tue, 14 May 2013 09:14:44 GMT Subject: Re: [PATCH 0/4] Coverage support revisited Message-ID: <87k3n16hyz.fsf@linux-k42r.v.cablecom.net> In-Reply-To: <51916A2B.3060001@web.de> Jens Lehmann 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