[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
tests.
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