<br><br><div class="gmail_quote">On Fri, May 8, 2009 at 1:12 PM, Mark Sienkiewicz <span dir="ltr"><<a href="mailto:sienkiew@stsci.edu">sienkiew@stsci.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Ned Batchelder wrote:<br>
> Another method would be to invoke coverage programmatically in the<br>
> daemon itself. This is less desirable because you have to modify your<br>
> product code to deal with testing issues, but would give you more<br>
> realistic measurement since the code really is running as a daemon.<br>
><br>
<br>
</div>"Design for test" has long been a standard practice in the hardware<br>
world. The idea is that you implement specific features in your design<br>
that you can later use to test whether the component is working. The<br>
final product contains testing features that are never activated by the<br>
end user.<br>
<br>
There is not necessarily a problem with modifying your code to include<br>
test features, and then leaving those features in the code when you<br>
deliver it. You just have to remember they are there, and code<br>
appropriately. e.g. Your test code should not bypass security<br>
restrictions unless that ability is explicitly enabled by the system<br>
administrator.<br>
<br>
Mark S.<br>
<div><div></div><div class="h5"><br>
<br></div></div></blockquote></div>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.<br>
<br>I am actually motivated to rebuild what I have to comply seamlessly with the tests.<br><br>And get that 100% coverage along with it.<br><br><br>