[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