[Twisted-Python] trial setUp/tearDown behavior

Jean-Paul Calderone exarkun at divmod.com
Tue Nov 15 13:53:24 EST 2005


To summarize the thread "Re: [Twisted-commits] r15100 - So I really do want this stuff":

me:
Why add testresource?

jml:
So I can reimplement setUpClass/setUp/tearDown/tearDownClass to not be broken.

james:
Can't you just call the functions in the right order?

jml:
No, since they have no shared object on which to operate.

james:
The application-developer thinks the TestCase instance is shared.

jml:
The application-developer is mistaken.  Also, using testresource will be more efficient.  Also, you have to set up your class with setUp, not __init__.

james:
That optimization changes semantics and breaks several Twisted TestCases.

me:
It does not seem surprising that setUp is for setting things up.

chorus:
It is surprising that setUp is for setting things up.

jml:
Using the TestCase instance as a location for shared state violates the unit-ness of the tests.


So, hopefully we're all caught up and have a clearer picture of what the problems which need to be solved are.

It seems as though using testresource to optimize setup/teardown isn't viable at this point, since it breaks tests in Twisted.  Maybe we can come up with a solution for this.

A main problem to coming to some agreement here seems to be that a lot of people are assuming they know how trial deals with shared state (or how trial should deal with shared state), but I haven't seen anyone explicitly spell this out yet.  Doing this might be a good first step to making further progress.




More information about the Twisted-Python mailing list