[TIP] Problem collecting coverage for D-Bus activated subprocesses
Gregory P. Smith
greg at krypto.org
Tue Aug 5 14:04:07 PDT 2014
This is the point where I tend to pull out strace to see what the processes
are actually doing (a failure to open a file to write coverage data to or
an open of a file in an unexpected place perhaps) but I don't know how easy
it would be for you to make D-Bus launch all child processes via strace -f
and store its output somewhere useful... (or you could have your early
process start-up code prior to enabling coverage re-exec itself under
On Tue, Aug 5, 2014 at 11:47 AM, Barry Warsaw <barry at python.org> 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
> 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
> That .ini file contains roughly:
> -----snip snip-----
> branch = true
> parallel = true
> omit =
> -----snip snip-----
> but after the full test suite runs I see only one .coverage file such as:
> meaning, that only the parent process is getting covered. I'd expect to
> 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
> both setting COVERAGE_FILE and chdir'ing to the proper directory. Neither
> 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:
> import coverage
> except ImportError:
> With some debug-printing in the else: clause, I can see that we get through
> 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.
> I'm stuck at the moment, so would appreciate in advance any thoughts on
> to try next or what I might be doing wrong.
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the testing-in-python