[TIP] Testing a daemon with coverage (nose)
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
> Mark S.
I totally agree about the value of in-code test structures (for example:
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...
More information about the testing-in-python