-
-
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
Fixture finalizer failure causes other finalizers to not be run #287
Comments
Original comment by holger krekel (BitBucket: hpk42, GitHub: hpk42): Independently of whether it's a good idea to do post-condition checking in teardowns (not really IMO), i wonder if we should guard each call of a finalizer. Not running finalizers due to an early failing one can bork the whole test run more than neccessary. |
Original comment by Peter Feiner (BitBucket: peterfeiner, GitHub: peterfeiner): I was also surprised to see the behavior that Andreas reported. The interaction with the tmpdir fixture is particularly painful. If tmpdir isn't "finalized" because an earlier finalizer failed, then the next test will use the previous test's tmpdir! I came across this issue when a finalizer threw an exception due to a bug in the test (the finalizer tried to wait() on a pid that the test had erroneously waited on). The bug in the test was non-deterministic and the probability of it appearing was only non-infinitesimal when 10+ tests were running in parallel using xdist. Hence, occasionally during heavy test runs I'd see a bunch of tests fail because they got very confused by files in their tmpdirs that had been left around by other tests. If a fresh tmpdir had been provided every time, then I would have just seen the test with the buggy wait() fail and presumably fixed it much sooner ;-) Here's a small test to demonstrate the problem with tmpdir:
And the output:
|
… (pull request #287) Include setup and teardown in junitxml test durations
Originally reported by: Andreas Pelme (BitBucket: pelme, GitHub: pelme)
When tearing down fixtures and one finalizer (registered via
request.addfinalizer
) fails (with an uncaught exception or withpytest.fail
) - no other finalizers will be run.Of course - the fixture finalizer could be fixed to not throw exceptions and the problem would go away.
However, I find it useful to be able to make assertions in the fixture teardown. I have a stubbing fixture (similar to pytest's monkeypatch). It checks that the stubbed methods actually was called during the tests, and triggers assertions otherwise. When this happens in one test case, it causes database fixture and all other kinds of failures for all other tests.
I am not sure this is a valid use case for fixtures, if not, feel free to close it. :)
The text was updated successfully, but these errors were encountered: