[Twisted-Python] Remove setupClass branch of trial - what is the motivation?

Itamar Shtull-Trauring itamar at itamarst.org
Fri Nov 4 12:02:43 MST 2005


On Thu, 2005-11-03 at 16:46 +1100, Jonathan Lange wrote:

> One big implication is that a TestCase isn't (necessarily) a
> self-contained TestCase.  It has to be wrapped in a ClassSuite to make
> sure that it gets properly set up and torn down.  Running a single
> test shouldn't require a suite.

I don't see why you need a ClassSuite; couldn't a TestCase have optional
pre- and post- hooks called along with the test?

> Oh yeah, and it makes things incompatible with unittest.

A correctly running trial (not what we have now, cause of all the tests
that do wait() and reactor.iterate()) would call reactor.run() once, and
tests would only support returning Deferreds as a mean for making the
reactor continue. Could we preserve unittest compatability while still
working this way? If not, there's no point in bothering. E.g. it seems
unlikely that a random unittest.py runner program will be able to run
trial tests once we switch to the correct reactor-running strategy.


> The example below shows what I'm considering at the moment.  This is
> the testresources system by Robert Collins.  One of the reasons I
> hesitated on this post is that I wanted to have chewed over this more.
> But here 'tis.

Any reason we need a whole complex new system when the current one
works?





More information about the Twisted-Python mailing list