|
Hi there, We have a test suite of approximately 4000 items. If we run pytest against the test directory it hangs at a certain test module every time (./testing/views/test_fred.py) . If we manually specify the all the test directories & put the directory with the test module that hangs first (eg pytest ./testing/views/test_fred.py ./testing/abc/test_abc.py ./testing/def/test_def.py ./testing/ghi/test_ghi.py ...) it works fine. If we just run the test module that hangs on its own it also works fine. I'd appreciate any guidance on how to get any additional logging/tracing information from pytest about what is happening & causing the test run to slow right down. Our environment:
Thanks in advance. Tim |
Replies: 1 comment
|
Hi @wonboyn The fact that the module runs successfully by itself and also works when moved earlier in the suite strongly suggests an order-dependent resource/state problem, although the information in the post is not enough to identify which resource. I would debug it in this order: pytest -vv
pytest -vv --setup-showThen run the hanging test together with progressively smaller subsets of the tests that precede it. That usually identifies the test which leaves behind the problematic state/resource. For a hang, pytest's built-in faulthandler support is particularly useful. For example in [pytest]
faulthandler_timeout = 30If execution is stuck for 30 seconds, pytest will dump Python thread stack traces, which can reveal a lock, network call, subprocess wait, etc. Because the versions in the post are Python 3.6 / pytest 6.2.5, I would also reproduce on a supported Python version and current pytest before treating this as a pytest-core bug. Please mark this answer as accepted if it helped, thank you. |
Hi @wonboyn
The fact that the module runs successfully by itself and also works when moved earlier in the suite strongly suggests an order-dependent resource/state problem, although the information in the post is not enough to identify which resource.
I would debug it in this order:
Then run the hanging test together with progressively smaller subsets of the tests that precede it. That usually identifies the test which leaves behind the problematic state/resource.
For a hang, pytest's built-in faulthandler support is particularly useful. For example in
pytest.ini:If execution is stuck for 30 seconds, pytest will dump P…