Arthur wrote: > .... One of the things I *did* do is develop > my own kind of test suite - having come to understand the importance of > doing so, for a futzer. On the other hand there isn't that there are > significant tests being passed now that wouldn't have been passed in an > earlier iteration. The tests are there mostly as an assurance that my > refactoring does not have me going backward. But offer no particular clue > about how to go forward. So, my kneejerk reaction to test based development > is some fear that it would lead to a development style that makes passing > tests good enough. On the other hand, I don't fully understand the workflow > that test based development recommends and where it leads. You'd have a lot of fun talking with Ward for a day. I am not completely sold on test-driven development myself, but I lean there which is why I call my current style test-forward. By that I mean I put the tests as early in the process as I can stand.
Two things that _are_ important in Ward's ideas and mine are: start with tests that fail and make them work. It is _shockingly_ easy to make a test that accidentally succeeds even in the face of bad code. More than once I've written a bad test, and eventually figured out that the test itself is bad. > When I do commercial work I have a pretty good idea where "good enough" is - > would the client (who doesn't really understand my process) want to pay for > further refinement (if they did understand my process). When I come to a > "no" - I stop. It's never that there aren't further refinements that could > be accomplished. In the for-money world, there are two other things Ward advocates. You break the work into tiny _costed_ chunks, some of which produce customer-visible results (and, perhaps) some of which do not). The ones you cannot make customer-visible get tied as pre-requisites to customer-visible chunks. You then let the customer choose what to work on next. The tests help confirm you are moving forward, not around. The estimates change, but the customer is tied in enough that he sees the new estimates each round. His choices are rarely the order you would choose, but they are his choices, not yours. Generally you try to make the chunks reflect equal amounts of work that are quickly terminable (half-day or day, for example). If you don't complete a task, you either put it back in the pile or (more likely) make new subtasks that finish this work. You track both your over-all progress, and the speed at which you dispatch tasks. You start calling your progress "four cards per week," for example. Your customer comes to see you hitting your estimates, and trusts the process more. You get better at estimating and teasing out prerequisites. You can even include tasks that are "break the goal into tasks" if the estimate is too shaky for your tastes. A couple of things I like about this model: it keeps you honest in promising what will happen, and it keeps your customer honest in that he is not asking for "free" work -- only costed trade-offs are available to choose from. --Scott David Daniels [EMAIL PROTECTED] _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig