-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
pytest 5.3.3: slow or crashing tests #6492
Comments
Can you git-bisect it then between 5.3.2 and 5.3.3, please? |
If the problem is between 5.3.2 and 5.3.3, one of those two fixes might be the culprit:
🤔 |
#6436 seems more likely, but perhaps in the sense that the fix broke some expectation on |
Running the two versions side by side, the performance hit is very noticeable, too. Result of
Full bisect:
|
Thanks @rixx. That confirms my suspicion that it is related to #6438. The fix might have caused a regression in |
I have the same issue without |
FWIW, pytest-django has a failing test (pytest-dev/pytest-django#801 (comment)): https://github.com/pytest-dev/pytest-django/blob/6528bc976dfd907fc5c63c659947371dbccb1f17/tests/test_db_setup.py#L310-L332 /cc @SalmonMode |
@mvbrn without pytest-django? |
@blueyed upd: downgrade to |
#6494 has more info, in particular that tests are using more fixtures all the time. |
From #6494 so the context is included here:
|
Pinned this issue as I suspect more people will hit this problem. |
That's very important information, thanks! Also can you please confirm that I'm thinking we should make a new hotfix release reverting #6403. Meanwhile, if someone can provide a MWE for us to study, it would be great, thanks! |
@nicoddemus I took a look at #6494 and it provided me with a clue. I'm not sure if this is the actual core of the issue, and I'm not even sure how this could have an impact, but it could be that function scope-level fixtures are registering their finalizers with autouse class scope-level fixtures when the test requesting the function scope-level fixture is not contained within a test class. I know how to prevent this from happening and can have a PR ready in a few minutes, but I have no idea how to recreate an issue caused by this, as the function scope-level fixtures should already have been torn down before the next test has a chance to run the autouse class scope-level fixture that would otherwise teardown the function scope-level fixture. |
@nicoddemus Yeah I can confirm that
I am going to test without any plugins installed at all, just to be sure it not one of them neither :). One last piece of information is the problem appears only with python 3.6, 3.7 is OK, didn't check other versions. Edit: Same issue with only |
@SalmonMode I don't have the time to create a MWE, but if you have a patch ready, I can test it directly, if that helps. Re Python versions, I'm running Python 3.7 in that virtualenv, so it's not 3.6 specific. |
@rixx that would be much appreciated! I'll have a branch ready in just a sec |
@rixx here's the branch https://github.com/SalmonMode/pytest/tree/fix-6492 |
@rixx would you mind trying the patch from #6504 with pytest, and pytest-dev/pytest-django#807 with pytest-django? |
That combination still shows the broken behaviour for me, as far as I can tell: Slow tests, and duplicate databases. |
@rixx this is a tough one. I really appreciate you taking the time to help with it! Are you by any chance using |
I'm not (or at least not to my knowledge). I'm running the pretalx test suite, you can run it yourself for testing purposes. |
@rixx I'm not able to get the same results as you. I'm running
Pytest also shows up in the pip list at the start of that command as this for me:
Here's the complete list it spat out:
|
This conversation has gotten somewhat spammy and uninformative for everybody else – I think further discussion would probably work better in private, if necessary – you can find my contact details here. I pushed a branch pinning the pytest and pytest-django versions here for reference.. |
@rixx @nicoddemus @blueyed @RonnyPfannschmidt I have a confirmed fix. The problem was with I'm currently looking into why the build for it fails. |
According to pytest-dev/pytest#6492 pytest 5.3.2 broke some things, so we should pin for now.
According to pytest-dev/pytest#6492 pytest 5.3.2 broke some things, so we should pin for now.
This is a regression test for part of pytest-dev#6492, testing one of the fixes in pytest-dev#6551.
This is a regression test for part of pytest-dev#6492, testing one of the fixes in pytest-dev#6551.
tl;dr: If your tests are slow or break on pytest 5.3.3, please pin
pytest==5.3.2
until this is resolved. A change to fixture handling seems incompatible with at least pytest-django, but also some non-Django projects.A change in 9918093 (part of the 5.3.3 release) led to an incompatibility regarding fixture handling/cleanup. It seems fixtures are not correctly recycled/collected, so they persist in unintended ways.
Original report with plenty of unimportant details inside:
The errors can be seen here:
or using MySQL:
The database name is supposedly generated by pytest-xdist, which is running on gw0 and gw1 in this Travis runner.
From my local debugging: It appears that initally, pytest-xdist will create databases called "test_pretalx_gw0" and so on, but then I see those disappear and be replaced by "test_pretalx_gw0_gw0", then "test_pretalx_gw0_gw0_gw0", and so on, while the tests are running. They aren't all replaced at the same time, and not for each test, but (I think) each time each thread opens a new module/test file.
I'm not sure if the fault rests with pytest, or pytest-xdist, or pytest-django, but it's only present as of the 5.3.3. bugfix release, with 5.3.2 running as intended (and significantly faster, at that). I'm reporting this here in hopes of help, and because while the error implies that the problem lies with either pytest-xdist or pytest-django, the change was definitely introduced on the side of pytest itself.
I'm happy to provide more details or debugging.
The text was updated successfully, but these errors were encountered: