<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Mark Sienkiewicz wrote:
<blockquote cite="mid:4A046809.3000203@stsci.edu" type="cite">
<pre wrap="">Ned Batchelder wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
"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.
</pre>
</blockquote>
I totally agree about the value of in-code test structures (for
example: <a class="moz-txt-link-freetext" href="http://nedbatchelder.com/blog/200902/you_asked_for_it.html">http://nedbatchelder.com/blog/200902/you_asked_for_it.html</a>).
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.<br>
<br>
--Ned.<br>
</body>
</html>