Repository navigation
Adding coverage support for C code tests - #833
Conversation
|
@hugovk You ok with this? |
|
Yes, good stuff! How does the timing differ covering those three versus the whole lot? |
|
These are the travis runs: Full set, ~52 total minutes: Just the three ~19 total minutes: vs with Python coverage only ~46 minutes total: Performance of individual runs seems similar for cpython, a little slower for pypy. |
|
Individual jobs take between ~30 seconds and ~2 minutes longer, so the start-to-end time, given parallel jobs, won't be so much more. Let's cover all for now, and can fine tune later as needed. |
Adding coverage support for C code tests
3 participants
Or, moving the goalposts for #722.
Currently, we're at 78.85%, 7160 of 9081 lines covered.
With this patch, we're at 73.57%, 14400 of 19573 lines covered.
So, we lose percentage, but gain instrumentation of 10k lines of code.
It installs a couple of extra packages, including, horror of horrors, a ruby gem. Using the extra bits, it combines the output json from gcov/lcov's c coverage with the json from coveralls-python. Then, the upload.
The coveralls-merge package can be found in my repo: https://github.com/wiredfool/coveralls-merge
Output can be found here: https://coveralls.io/builds/1029743 , especially this file: https://coveralls.io/files/257210494
Performance ranges from not bad to a somewhat worse than just python coverage. We may want to consider covering 2.7+sitepackages, 3.4, and maybe one of the pypys, as that should get us accurate to within a few lines of coverage. (edit, according to my tests, those three (2.7+site, 3.4, pypy2.3) gets us +- 1 line of coverage compared to all 8 of them.)