[TIP] Testing a daemon with coverage (nose)

Ned Batchelder ned at nedbatchelder.com
Fri May 8 10:50:50 PDT 2009

Mark Sienkiewicz 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.
I totally agree about the value of in-code test structures (for example: 
http://nedbatchelder.com/blog/200902/you_asked_for_it.html).  I 
mentioned it as a trade-off to make between testing smaller components 
to avoid the daemonization, or adding in test harnesses to test as-is.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.idyll.org/pipermail/testing-in-python/attachments/20090508/02eba1f7/attachment.htm 

More information about the testing-in-python mailing list