[TIP] Testing a daemon with coverage (nose)

Alfredo Deza arufuredosan at gmail.com
Fri May 8 10:42:15 PDT 2009

On Fri, May 8, 2009 at 1:12 PM, Mark Sienkiewicz <sienkiew at stsci.edu> wrote:

> Ned Batchelder wrote:
> > 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.
> >
> "Design for test" has long been a standard practice in the hardware
> world.  The idea is that you implement specific features in your design
> that you can later use to test whether the component is working.  The
> final product contains testing features that are never activated by the
> end user.
> There is not necessarily a problem with modifying your code to include
> test features, and then leaving those features in the code when you
> deliver it.  You just have to remember they are there, and code
> appropriately.  e.g. Your test code should not bypass security
> restrictions unless that ability is explicitly enabled by the system
> administrator.
> Mark S.
> Wow, now that I am actually entering the "testing world" with the code I am
producing, I see why would I end up with a much better code base just
because I would need to think about design related to testing when coding.

I am actually motivated to rebuild what I have to comply seamlessly with the

And get that 100% coverage along with it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.idyll.org/pipermail/testing-in-python/attachments/20090508/f324c9e7/attachment.htm 

More information about the testing-in-python mailing list