[Tutor] Where to start with Unit Testing

[David Hutto]

On Sun, Aug 1, 2010 at 9:31 PM, David Hutto <smokefloat at gmail.com> wrote:
> 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
>>
>>
>

Disclaimer: I have no clue what unit testing is, nor have I had to use it yet.