[Twisted-Python] trial setUp/tearDown behavior
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":
Why add testresource?
So I can reimplement setUpClass/setUp/tearDown/tearDownClass to not be broken.
Can't you just call the functions in the right order?
No, since they have no shared object on which to operate.
The application-developer thinks the TestCase instance is shared.
The application-developer is mistaken. Also, using testresource will be more efficient. Also, you have to set up your class with setUp, not __init__.
That optimization changes semantics and breaks several Twisted TestCases.
It does not seem surprising that setUp is for setting things up.
It is surprising that setUp is for setting things up.
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