Hi,<br><br><div><span class="gmail_quote">On 4/17/07, <b class="gmail_sendername">Kumar McMillan</b> <<a href="mailto:kumar.mcmillan@gmail.com">kumar.mcmillan@gmail.com</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;">
As for TDD, everyone has their own style, but to answer your question<br>in the way I would do it...<br><br>1. write functional tests at the highest level for all the features<br>you want to release [1] so that they are all failing. The highest
<br>level might be accessing the queue interface (is it a web app?) adding<br>an item, seeing that it shows up in the list view, deleting, etc.<br>2. implement just enough code so that they pass.<br>3. At this point you may want to experiment with a few better
<br>implementations so keep coding<br>4. decide on an implementaion and write unit tests for all the units involved<br>5. start back at number 1 with new features you want to add. Add to<br>any existing unit tests if the features calls for the modification of
<br>those units</blockquote><div><br>
My recent experience with #1 has been very positive. I found that
writing functional tests for web app is (can be?) _very_ cost
effective: you can test so much with so little code (and a pile of
infrastructure code, but that's a different story). <br>
<br>
Granted, these tests are coarse-grained and they tend to produce binary
answer (still works vs. broken). Unit tests gives answer on which unit
is broken but they can be a real drag while you refactoring and
functional tests obsoletes much slower.<br>
</div><br>
Max.<br>
<br>
</div><br>