[TIP] Testing a daemon with coverage (nose)

Mark Sienkiewicz sienkiew at stsci.edu
Fri May 8 10:12:41 PDT 2009

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 

Mark S.

More information about the testing-in-python mailing list