/usr/share/doc/lire/dev-manual/ch16s04.html is in lire-devel-doc 2:2.1.1-2.1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | <html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Some “Best Practices” on Unit Testing</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Lire Developer's Manual"><link rel="up" href="ch16.html" title="Chapter 16. Making Lire “Test-infected”"><link rel="prev" href="ch16s03.html" title="Running Tests"><link rel="next" href="ch17.html" title="Chapter 17. Commit Policy"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Some <span class="quote">“<span class="quote">Best Practices</span>”</span> on Unit Testing</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch16s03.html">Prev</a> </td><th width="60%" align="center">Chapter 16. Making Lire <span class="quote">“<span class="quote">Test-infected</span>”</span></th><td width="20%" align="right"> <a accesskey="n" href="ch17.html">Next</a></td></tr></table><hr></div><div class="section" title="Some “Best Practices” on Unit Testing"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id417742"></a>Some <span class="quote">“<span class="quote">Best Practices</span>”</span> on Unit Testing</h2></div></div></div><p>This section lists some tips on how to make
effective use of Unit tests in common development
situations on Lire.
</p><p title="Changing interface/implementation"><b>Changing interface/implementation. </b>Before changing a module interface or implementation,
make sure that this module has test cases and that it
passes its tests before changing the implementation. This
way you can know that your changes didn't break anything.
</p><p title="Debugging"><b>Debugging. </b>A good opportunity for writing tests is when bugs are
reported. Before trying to chase the bug using the
debugger or adding <code class="function">print</code> statements,
write a test case that will fail as long as the bug isn't
fixed. This achieves two purpose: first, you'll know when
the bug is fixed as soon as the test pass; secondly, we
now have a test case that will warn us if we regress and
the bug reappears.
</p></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch16s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch16.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch17.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Running Tests </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 17. Commit Policy</td></tr></table></div></body></html>
|