[Tutor] Where to start with Unit Testing

[David Hutto]

On Sun, Aug 1, 2010 at 9:11 PM, Che M <pine508 at 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  -  Tutor at python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/mailman/listinfo/tutor
>
>