-
-
Notifications
You must be signed in to change notification settings - Fork 525
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
13.1: pytest fails in 3 units #1509
Comments
After add those tree units to --deselect list ne units popped oud so looks like there are some dependencies between units (probably it would be good to test test suite using https://github.com/mrbean-bremen/pytest-find-dependencies/). --deselect tests/asyncio/test_client.py::ClientTests::test_keepalive_is_enabled \
--deselect tests/asyncio/test_connection.py::ClientConnectionTests::test_close_waits_for_close_frame \
--deselect tests/asyncio/test_connection.py::ClientConnectionTests::test_close_waits_for_connection_closed \
--deselect tests/asyncio/test_connection.py::ServerConnectionTests::test_close_waits_for_close_frame \
--deselect tests/asyncio/test_server.py::ServerTests::test_close_server_keeps_handlers_running \ |
☝️ Just skip this step — it doesn't serve a purpose. |
Probably you're taking this step because you believe that it serves a purpose. We can disagree on this. As consequence of this disagreement, I'm choosing not to invest my time into debugging this problem. Perhaps you have constraints like "if a git repository related to the library contains various test suites, you must pick at least one of them and run it, although it doesn't matter very much which one you choose". (There are three test suites in the repo.) If you have that kind of constraint, then the test suite that you chose is the easiest to run, so stick with that one, even if it's completely inadequate to the environment where you're running it. You may re-run until you get a non-flaky run. You may or may not get a successful run eventually, depending on details of your environment. You may try setting the |
I don't think that's the problem. The problem is that I'm using extremely short timings for testing in order to keep the test suite fast; obviously that makes it flaky if you run it in a slower or less stable environment. All failing tests that you observe involve timings or timeouts. |
I've tested with WEBSOCKETS_TESTS_TIMEOUT_FACTOR=100 and pytest os OK. |
I'm packaging your module as an rpm package so I'm using the typical PEP517 based build, install and test cycle used on building packages from non-root account.
python3 -sBm build -w --no-isolation
build
with--no-isolation
I'm using during all processes only locally installed modulesinstaller
modulecut off from access to the public network
(pytest is executed with-m "not network"
)Here is pytest output:
List of installed modules in build env:
Please let me know if you need more details or want me to perform some diagnostics.
The text was updated successfully, but these errors were encountered: