Re: [PATCH 0/4] Coverage support revisited
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 relly 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
Re: [PATCH 0/4] Coverage support revisited
Thomas Rast tr...@inf.ethz.ch writes: Below is the coverage-untested-functions output; it seems submodule.c is covered, so there is nothing for Jens to do ;-) Nice. Here are some hints to add coverages to the selected functions. alloc.c: report alloc.c: alloc_report I believe these are only for debugging. archive-tar.c: write_extended_header Need to create an archive that contains loong pathname (iirc, over 100 bytes) in the test. attr.c: git_etc_gitattributes builtin#add.c: ignore_removal_cb --ignore-removal option parsing. builtin#apply.c: checkout_target Try git apply --index to an empty working tree with a valid index. builtin#apply.c: add_name_limit builtin#apply.c: option_parse_exclude builtin#apply.c: option_parse_include git apply --exclude/include. builtin#apply.c: option_parse_z git apply --stat -z. builtin#blame.c: read_ancestry git blame -Sfile. builtin#blame.c: sanity_check_refcnt Only used for debugging. builtin#blame.c: prepare_initial git blame --reverse. builtin#blame.c: blame_move_callback git blame -M (option parsing). varint.c: decode_varint varint.c: encode_varint git update-index --index-version 4 and then read from the resulting index. -- 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
Re: [PATCH 0/4] Coverage support revisited
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 relly 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
