[TIP] Testing a daemon with coverage (nose)

[Ned Batchelder]

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.

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