avoiding long startup time in unit testing

Michele Simionato michele.simionato at gmail.com
Sat Jul 3 09:06:34 CEST 2004


There are situations in which you have to setup a faily sophisticated
environment before running your tests. This may result in a long
startup
time. In my case (using PloneTestCase) the time taken to import all
the
needed libraries, create a plone site and set up the environment, is
so
long that practically I cannot use my good old Pentium II for running 
the test cases. Notice that the problem is not in the time spent on
the
tests which is really marginal (I typically run only one or two tests,
I am not talking about running the full test suite), it is all startup
time. This is terrible for me since I usually run the tests often
(say every minute) and if I have a minute of startup time at each run
my productivity is cut in half. It is essentially the same feeling
that
using a compiled language :-(

So, you could tell me "Why don't you use your newer, much faster
laptop
and you are done with it?". The answer is that I have a special
affection
for my old laptop ;) I did a lot of Python work with it and it is
still
fast enough for most applications.

The problem is with the testing framework. If I am just fixing a 
misprint in my test case I don't want all the plone site to be
recreated from zero, I want just to re-run the fixed test. For
instance, I would like to highlight the given test with Emacs and
run it, without recreating the site each time.

I did some experiment hacking unittest and I can get something
interesting,
such as a command-line interface where you initialize the stuff only
once,
you reload the module you want to test, and you run the tests for that
module.

However, this is a hack, and I don't know how much robust it is
(probably not
very). I wonder and I ask here on the mailing list if there is already
some
testing framework that does what I am talking about.
I am interested in something general, not necessarely related to
Zope/Plone.
Thanks,

            Michele Simionato



More information about the Python-list mailing list