geoff.bache at gmail.com
Sun Oct 31 12:25:58 PDT 2010
> 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
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?
More information about the testing-in-python