[TIP] Testing a daemon with coverage (nose)

C. Titus Brown ctb at msu.edu
Fri May 8 06:40:19 PDT 2009

On Fri, May 08, 2009 at 08:58:57AM -0400, Alfredo Deza wrote:
-> On Fri, May 8, 2009 at 7:24 AM, Ned Batchelder <ned at nedbatchelder.com>wrote:
-> > Alfredo Deza wrote:
-> >
-> > I'm not sure I've got all the details right, but it sounds like the basic
-> > problem is that you have a test that nose can measure, but that test spawns
-> > a new process, and the code in the new process is not measured.  Ironically,
-> > I have the same problem when coverage-testing coverage.py!
-> > One possibility is to remove daemonization from the test run.  This is
-> > similar to the testing technique of using test doubles to remove complicated
-> > dependencies from tests.  If your code is organized so that the main() of
-> > the daemon is callable directly, you can write a test that invokes the main
-> > directly, rather than in a separate process, and measure code coverage that
-> > way.
-> >
-> > Another method would be to invoke coverage programmatically in the daemon
-> > itself.  This is less desirable because you have to modify your product code
-> > to deal with testing issues, but would give you more realistic measurement
-> > since the code really is running as a daemon.
-> You are correct, the test spawns a new process.
-> I like the idea of removing the daemonization from the test run, or testing
-> all the way up to when the module kicks the daemonization call.

In addition the various intrusive ways of adding coverage recording into
your daemon (environment variables, configuration settings, etc.) we
talked briefly about putting 'import figleaf; figleaf.start()' into
site.py at PyCon.  Not sure whether or not that would work, though.

A better way might be to instrument the code that starts the daemon to
explicitly start the daemon with code coverage.  It doesn't require
modifying the daemon code, but it might require reaching deep into the
guts of your app depending on how it's organized.

C. Titus Brown, ctb at msu.edu

More information about the testing-in-python mailing list