Merge lp:~mvo/click/coverage into lp:click/devel
Proposed by
Michael Vogt
Status: | Merged |
---|---|
Approved by: | Colin Watson |
Approved revision: | 462 |
Merged at revision: | 457 |
Proposed branch: | lp:~mvo/click/coverage |
Merge into: | lp:click/devel |
Diff against target: |
200 lines (+59/-13) 6 files modified
.coveragerc (+2/-0) click/tests/__init__.py (+11/-2) click/tests/gimock.py (+32/-10) debian/control (+1/-1) debian/rules (+6/-0) doc/index.rst (+7/-0) |
To merge this branch: | bzr merge lp:~mvo/click/coverage |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Colin Watson | Approve | ||
Review via email: mp+221871@code.launchpad.net |
Description of the change
This branch runs the tests with the python{,3}-coverage framework (if its installed). This gives us details about the test code coverage and can also be used to report to the QA dashboard. The coverage data is generated during the build so that jenkins can pick it up.
Feedback welcome, especially if the gimock.py changes can be done in a different/more elegant way :)
To post a comment you must log in.
On Jun 09, 2014, at 01:41 PM, Colin Watson wrote:
>It looks like this will always re-exec with python-coverage, even if the test
>suite was run with bare python. This seems a bit inconsistent. It would be
>nice to only switch to the coverage executable if we were running under
>coverage to start with. How about 'if "coverage" in sys.modules' as a way to
>test for that?
I'm working on getting coverage for system-image, including the dbus
subprocesses. There's this page:
http:// nedbatchelder. com/code/ coverage/ subprocess. html
I think it makes sense to set the envar COVERAGE_ PROCESS_ START and check for
that to know whether you're running under coverage or not.
>I know os._exit(0) caused problems for coverage, but I'm a bit concerned
>about accidentally returning into test code and causing havoc. How about
>sys.exit(0) instead, which should still generate coverage data but will
>ensure we don't double-run test code?
sys.exit() raises a SystemExit exception, but os._exit() calls exit(2), so the
latter doesn't give Python a chance to intervene.