On Sun, Aug 1, 2010 at 9:39 PM, David Hutto <smokefl...@gmail.com> wrote: > On Sun, Aug 1, 2010 at 9:31 PM, David Hutto <smokefl...@gmail.com> wrote: >> On Sun, Aug 1, 2010 at 9:11 PM, Che M <pine...@hotmail.com> wrote: >>> >>> >>>> > The idea of unit testing/test driven development has remained >>>> > foreign to me throughout my time trying to learn Python--by choice. >>>> > I want to make desktop GUI applications and I don't use MVC, so >>>> > the idea of writing tests strikes me as far more work--and a major >>>> > delayer of getting to an application that actually does something-- >>>> > than simply using the software myself and noting problems. It >>>> > sounds like TDD is probably the most proper way to go about things, >>>> > but, in the interest of getting something out of Python to warrant the >>>> > time I've put into it, I favor a "good enough" approach for now. >>>> >>>> Writers just call this a rough draft. Perfection is in the revisions >>>> that come after a little thought. >>> >>> Well, I don't see what I'm doing as a rough draft, as I am attempting >>> to hone it to "perfection" (that is, a working app)--just without unit >>> testing. >> >> Every time you try to perfect is a revision of your initial 'written' >> algorithm. From concept forward is your revisions. Notice that svn and >> cvs are called revisions. How quickly is a different story. To you, >> your writing and rewriting, but each rewrite is a revision of the >> initial concept. And as far as i can tell, if you want to be the unit >> test yourself, it's fine, but unit testing might be inappropriate for >> something like this. But basically unit testing would be a script that >> inputs the possible combinations of requests to the original script, >> which should be tested like chefs do soups-intermittently as you >> design it. So the tests are really what you put or type as input given >> directly to the script , right?. >> >> >> >>> >>> A different analogy comes to my mind; I once saw two different sets of >>> people analyze data. One did it "by hand": visually inspecting thousands >>> of signals herself and typing Y or N to accept or reject each signal. The >>> other did it with an automated system that accepted or rejected signals >>> based on fuzzy logic. >> >> This depends on your need for control, do you need to manually accept, >> or can you just detect the signal, and let the program proceedl. Do >> you want the local nuclear plant to have their system throw an error, >> without a human response? >> >> In an important interpretation, the automated system >>> was far better, and yet the first scientist was done with her analysis and >>> accepted for publication before the second team even had the bugs worked >>> out of the automated system! >> >> Like you state below, the automated system used, evolved from manually >> designed systems, so automation is the easy way, but sometimes not the >> best, depending on the circumstance and priority level of the >> information being received. >> >> Yes, I think the slow-but-more-proper team >>> did the more correct thing, but there is something to be said for "good >>> enough", too (it works for evolution, for example). >> >> >>> >>> >>> >>> >>> _______________________________________________ >>> Tutor maillist - tu...@python.org >>> To unsubscribe or change subscription options: >>> http://mail.python.org/mailman/listinfo/tutor >>> >>> >> > > Disclaimer: I have no clue what unit testing is, nor have I had to use it yet. >
But it would be a series of function instances from a module, right? Not to butt in on the OP. _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor