-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Teardown should always occur #917
Comments
my personal impression is that more fine-grained finalizer's are needed the thing is robust setup/tear-down is practically only possible if the setup registers all finalizes and there is no fully grown tear-down (because else someone will always do tear-down wrong if given the chance) |
IIRC we reverted at some point towards the unittest/nose behaviour of only running teardown when setup succeeded. I wouldn't like to change this now again. Note that with pytest fixtures can call |
Note even the blogpost you linked says:
|
Yes, I did read the author's stance change, as well as the comments about Is this well documented though? I found no mention of this here: Coming from .NET and xUnit, where I don't really have to think about those things, I can simply create a constructor and a |
talking about xUnit, if pytest used |
You can never be sure |
Similar to what I said in #918, I consider |
To illustrate what @The-Compiler is saying, I just posted an example of replacing |
teardown should always occur even if setup fails.
http://pythontesting.net/framework/unittest/unittest-wrong-teardown/
consider the following
teardown never occurs.
The real-world scenario would be similar to this:
http://effbot.org/zone/python-with-statement.htm
This is the correct usage if multiple resources need to be used simultaneously and cleaned up after.
Here's a real world testing scenario:
if
x.txt
exists, buty.txt
does not exist, we have no chance to closeself.f
.The text was updated successfully, but these errors were encountered: