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. _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
