[Tutor] Where to start with Unit Testing

David Hutto smokefloat at gmail.com
Mon Aug 2 03:42:10 CEST 2010


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

But it would be a series of function instances from a module, right?
Not to butt in on the OP.


More information about the Tutor mailing list