[Twisted-Python] trial setUp/tearDown behavior
Jean-Paul Calderone
exarkun at divmod.com
Tue Nov 15 11:53:24 MST 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