[TIP] Testify

holger krekel holger at merlinux.eu
Mon Nov 1 10:59:18 PDT 2010


Hi Geoff!

On Sun, Oct 31, 2010 at 20:25 +0100, Geoff Bache wrote:
> > Right, intelligent grouping is one difficulty.  Another is to have an
> > extension architecture that allows plugins to work in distributed situations
> > as well.  E.g. coverage, profiling, junitxml-reporting etc.  Thirdly, when
> > we distribute tests to non-homogenous environments (instead of just
> > subprocesses on a local machine) there also is a deployment issue - how to
> > prepare (remote) environments so that we can run our tests properly?
> >
> > I believe that the last bit could be helped by making "tox" provide an API
> > so that we can reuse/extend tox.ini files to create environments, especially
> > since there is an upcoming "zero-installation" way now to bootstrap tox on
> > any machine.
> 
> My black-box acceptance test tool, TextTest, supports parallel test
> running by integration with grid engine programs, i.e. programs like
> Sun Grid Engine, LSF, Condor. This adds to the complexity of setting
> things up for the user but means that a lot of the issues around
> preparing remote environments and the details of distribution are
> fixed by the grid engine and the test tool doesn't need to reinvent
> the wheel in this sense.  It also means you get queueing functionality
> and load balancing along: useful if lots of developers want to run the
> same tests in parallel on the same pool of machines.
>
> Has anyone else among tool maintainers looked into supporting parallel
> test runs this way?

Haven't used them. Only Hudson and buildbot - which IMO require too much 
configuration and maintenance work already.  They don't come with much
support for Python's best testing practises.  Tox tries to fill this gap.
Most importantly: you can also use it from the command line which despite 
the existence of cloud/grid/web2 shenanigans is worth something to me :)

cheers,
holger



More information about the testing-in-python mailing list