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
time. In my case (using PloneTestCase) the time taken to import all
needed libraries, create a plone site and set up the environment, is
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
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
using a compiled language :-(

So, you could tell me "Why don't you use your newer, much faster
and you are done with it?". The answer is that I have a special
for my old laptop ;) I did a lot of Python work with it and it is
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
such as a command-line interface where you initialize the stuff only
you reload the module you want to test, and you run the tests for that

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
testing framework that does what I am talking about.
I am interested in something general, not necessarely related to

            Michele Simionato

More information about the Python-list mailing list