[TIP] Problem collecting coverage for D-Bus activated subprocesses

Ned Batchelder ned at nedbatchelder.com
Tue Aug 5 14:51:12 PDT 2014

On 8/5/14 2:47 PM, Barry Warsaw wrote:
> I have a Python 3 project with an extensive test suite for which I want to
> gather coverage data.  I use nose2 as the test runner.  While I get accurate
> coverage for the parent process tests, covering subprocesses just isn't
> working afaict.
> I suspect the tricky part here is that the subprocesses are D-Bus services
> which get activated via a custom system bus run with dbus-daemon.  However,
> I've verified that environment variables are being seen by these subprocs,
> including COVERAGE_PROCESS_START which points to the correct coverage.ini
> file.
> That .ini file contains roughly:
> -----snip snip-----
> [run]
> branch = true
> parallel = true
> omit =
>       setup*
>       ...
> -----snip snip-----
> but after the full test suite runs I see only one .coverage file such as:
> .coverage.<hostname>.<parent-pid>.<random>
> meaning, that only the parent process is getting covered.  I'd expect to see
> about a dozen subproc .coverage files.
> When I debug-print the D-Bus activated subprocs, I can see the environment
> variable, and its pid, along with its cwd, which is /.  Thinking that maybe
> coverage is trying to write the default .coverage.* files in cwd, I've tried
> both setting COVERAGE_FILE and chdir'ing to the proper directory.  Neither has
> worked.
> My subprocs start coverage like so, early on in their main().
>      ini_file = os.environ.get('COVERAGE_PROCESS_START')
>      if ini_file is not None:
>          try:
>              import coverage
>          except ImportError:
>              pass
>          else:
>              coverage.process_startup()
> With some debug-printing in the else: clause, I can see that we get through
> coverage.process_startup().
> Still, I get no data from the subprocs.  My tests that activate the service
> all pass, so I know the subprocs are running.
> My only guess at the moment is that setting [run]parallel=true in the .ini
> file isn't enough to turn on parallel mode.  I can't really pass
> -p/--parallel-mode to the subprocesses so I'm relying on .process_startup() to
> get coverage going.

Your data file has the machine name, pid, and random number, which is an 
artifact of parallel mode, so that seems fine.

Could it be due to an os._exit() after forking? 

If you have ideas about how to support that, I'm open to them.

> I'm stuck at the moment, so would appreciate in advance any thoughts on what
> to try next or what I might be doing wrong.
> Cheers,
> -Barry
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20140805/7ad3c611/attachment.htm>

More information about the testing-in-python mailing list