<br><br><div><span class="gmail_quote">On 4/24/07, <b class="gmail_sendername">Titus Brown</b> <<a href="mailto:titus@caltech.edu">titus@caltech.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
-> I coded a huge test suite once that primarily unit tested<br>-> implementation. Since there were many tests, any time I wanted to<br>-> change the way the app was implemented (faster algorithm here, don't
<br>-> need this class anymore, more methods now because of feature X) I<br>-> usually ended up spending a good deal of time updating and deleting<br>-> tests. This just seemed unecessary to me and deterred me from relying
<br>-> on the test suite as an indication of successful functionality.<br><br>So, isn't this kind of an argument for functional and regression tests<br>only?<br><br>(I'm honestly curious. I haven't found much of a need for unit tests in
<br>my own code.)</blockquote><div><br>
Functional tests work great when testing "base path" through the
system. But they don't work that great testing corner cases, unexpected
conditions and branch logic. <br>
<br>
You can write unit tests which exercise a function/module with (all)
different code paths. The more high-level the test the less feasible it
becomes: number of permutations explodes and many code paths simply
aren't (easily) reachable from the top-level. That off-the-beaten-path
code still needs to be tested and there is no better tool for that than
unit tests.<br>
<br>
YMMV, of course.<br>
<br>
Max. <br>
</div></div>