[Tutor] I don't get it

Magnus Lycka magnus@thinkware.se
Fri, 20 Sep 2002 19:53:34 +0200


At 09:34 2002-09-20 -0700, Sean 'Shaleh' Perry wrote:
>breaking the name down it means testing in small units of=20
>functionality.  Each
>function/class/whatever in a module would have one or more test functions
>written which verify proper behavior.  As you said the main block provides=
 a
>way to run these tests in an elegant manner.

Every public *method* in every class should have a unit test.

There is an excellent module called "unittest" in the
python standard library.

See http://www.thinkware.se/cgi-bin/thinki.cgi/PyUnitExample
and http://www.python.org/doc/current/lib/module-unittest.html
and http://pyunit.sourceforge.net/

According to Extreme Programming you should always write tests
before writing the code you try to test. When your code passes
all your tests you stop coding, since then you are done. See
http://www.thinkware.se/cgi-bin/thinki.cgi/ExtremeProgramming

A complimentary Extreme Programming practice is refactoring,
which means that you continually fix your program structure
when you find flaws. (Adding/changing functionality and
refactoring code are separate processes in XP. When you add
or change functionality you always add or change unit tests.
When you refactor you *never* change your tests. They should
all run both before and after each refactoring.)

A development session using unit testing and refactoring is
sescribed here:
http://www.xprogramming.com/xpmag/refactoringisntrework.htm

These development practices are very useful even if you
don't run a full extreme programming project. Writing test
first mean that:
  * You have to think through requirements before coding.
  * You avoid goldplating code since you get a signal to
    stop coding. "All test are OK. I'm done coding."
  * The test cases can be used as examples on how to use
    your classes and functions. Useful for other coders.
  * Obviously, the unit tests will warn you when you make
    coding mistakes.
  * You don't have to worry about breaking functionality
    when you refactor your code, since you make changes in
    small steps and continually check that all tests are OK.

This requires that you learn how to refactor, i.e. how to
change the design of your code in small evolutionary steps
without breaking functionality. It's a very Darwinistic
approach to programming. Just like with the evolution of
organisms, big leaps in developemnt can't happen. Each
generation (successful test run) can only be slightly
different from the previous.

Regarding use of "if __name__ =3D=3D '__main__':" I usually
place my test code in separate files. For moduleX.py
I will have a moduleX_ut.py. I then have a small script
that will run all the test scripts in a project directory.

Another way of doing unit testing in Python is the
doctest module, that will let you specify tests in the
documentation strings for functions, methods etc. See
http://www.python.org/doc/current/lib/module-doctest.html


--=20
Magnus Lyck=E5, Thinkware AB
=C4lvans v=E4g 99, SE-907 50 UME=C5
tel: 070-582 80 65, fax: 070-612 80 65
http://www.thinkware.se/  mailto:magnus@thinkware.se